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?
[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):
It seems the explicit chmod() spoils things.
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.)