Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have an application that generates report files in /opt/reports with files owned root:root at 0600. In an attempt to allow an external system to automagically process these reports I created a new service account user with group ‘report’, changed the group for /opt/reports to report and set the SUIG bit, then set the default ACL on the/opt/reports directory to include report group with 400 and mask with 400.

I notice that when I manually create a file the permissions are all set as expected, however when the application creates a file the defaults are not inherited.

[root@reports1 ~]# getfacl /opt/reports
getfacl: Removing leading '/' from absolute path names
# file: opt/reports
# owner: root
# group: report
user::rwx
group::r-x
other::r-x

[root@reports1 ~]# setfacl -R -d -n -m g:report:r,m::r /opt/reports/
[root@reports1 ~]# getfacl /opt/reports
getfacl: Removing leading '/' from absolute path names
# file: opt/reports
# owner: root
# group: report
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x              #effective:r--
default:group:report:r--
default:mask::r--
default:other::r-x

Creating the file manually seems to work ok

[root@reports1 ~]# echo "This is a test file" > /opt/reports/testfile.txt
[root@reports1 ~]# ls -l /opt/nessus_reports/testfile.txt
-rw-r--r--+ 1 root report 20 Apr 24 11:16 /opt/reports/testfile.txt
[root@reports1 ~]# getfacl /opt/reports/testfile.txt
getfacl: Removing leading '/' from absolute path names
# file: opt/reports/testfile.txt
# owner: root
# group: report
user::rw-
group::r-x                      #effective:r--
group:report:r--
mask::r--
other::r--

When generating a report with the application, however, the mask does propagate out to the new file

[root@reports1 ~]# ls -l /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
-rw-------+ 1 root report 125952 Apr 24 11:18 /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
[root@reports1 ~]# getfacl /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
getfacl: Removing leading '/' from absolute path names
# file: opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
# owner: root
# group: report
user::rw-
group::r-x                      #effective:---
group:report:r--                #effective:---
mask::---
other::---

Is this expected behavior, and I am simply misunderstanding the terminology involved? Did I miss a flag or option somewhere, am I approaching it from the wrong direction entirely?

share|improve this question
add comment

2 Answers 2

[First of all, it seem your SUIG bit is lost (I'd expect a "flags: -s-" in the getfacl output). However, that's not what's causing the issue here.]

It seems that the report generator not only creates the file with a 027 umask, but also does an explicit chmod() on the file. When it does that, the POSIX ACL mask is lost.

Try the following (as root):

touch /opt/reports/testfile.txt
getfacl /opt/reports/testfile.txt

chmod 640 /opt/reports/testfile.txt
getfacl /opt/reports/testfile.txt

It seems the explicit chmod() spoils things.

share|improve this answer
    
Interesting. That's pretty cute. I'll have to see if i can get my hands on that software and mock up a test again. I should be able to track it with auditd –  Scott Pack May 12 at 12:12
add comment

This is the default behavior, because files when created have the user:group association of the user that creates them. There is still hope, though. You just have to make sure that when the application is ran, it is ran by a user that has the report group as their primary group. There are plenty of examples of how to do this out there. If you look at some of the scripts in /etc/init.d almost all of them do this when starting a service. Good luck! (On a side note, it kind of shows that you're a windows admin, since the whole inheriting permissions on child objects is the default on windows style permissions, the mental switch to unix style acl's on files can be a little tricky.)

share|improve this answer
    
Your answer does address most of the limitations of traditional Unix permissions, but there are two problems here: 1) When the SUIG bit is set then new files or directories are owned by the specified group, without regard to the user's primary group, 2) Inheritance is a feature of POSIX acls. –  Scott Pack Apr 25 '12 at 16:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.