Setting explicit ACLs per entity in linux
A quick internet search reveals a set of commands used to manage discretionary access control lists of files in linux. setfacl and getfacl are tools included with the acl package that allow you to manage the ACLs of files.
As long as the device’s file system’s are mounted to consider ACLs (see “Setting POSIX System ACLs for the RA“), then the following will work as intended.
I recently posted about allowing Samba access to a set of files that are served using httpd, where I describe changing the SElinux security context of those files to allow httpd and smbd to access the files. Not fully verifying all the layers of access, I still faced issues with no access due to the file level ACLs.
Install the tools:
yum -y install acl
Our system-wide user is backuprobot.
I want to make sure that backuprobot has read access to /reporoot/* and /var/www/*.
[root@server ]# getfacl /reporoot/ getfacl: Removing leading '/' from absolute path names # file: reporoot/ # owner: paste # group: paste user::rwx group::r-x other::r-x
Okay, so just like we would see if we used ls -al, we can see that the other POSIX entry is allowed read access, at least to the directory.
The backup job that failed reported access problems to specific files… so let’s take a look at those files:
[root@server ]# getfacl /var/www/rhodecode-venv/data/templates/ getfacl: Removing leading '/' from absolute path names # file: var/www/rhodecode-venv/data/templates/ # owner: paste # group: paste user::rwx group::r-x other::r-x
Okay, so the other POSIX entry still has read rights to the directory.
Let’s take a look at the specific file then:
[root@server ]# getfacl /var/www/rhodecode-venv/data/templates/index.html.py getfacl: Removing leading '/' from absolute path names # file: var/www/rhodecode-venv/data/templates/index.html.py # owner: paste # group: paste user::rw- group::--- other::---
Finally, we see only the user paste has any rights to this file.
Now that we’ve confirmed the “problem,” we can go ahead and resolve the issue by granting the backuprobot user explicit read access to every single file in the directories we wish it to have read access by using the setfacl tool.
setfacl -R -m user:backuprobot:rx /reporoot setfacl -R -m user:backuprobot:rx /var/www
This recursively (‘-R’) modifies (‘-m’) the ACL of the given file(s) and adds the entry as described, granting backuprobot the read and execute permissions.
Note that you might still see “access denied” for some “files,” except these files aren’t files at all but symlinks! Use the following command to find symlinks below a the /var/www/ directory:
find /var/www/ -type l
Your backup software more than likely has a setting to follow or not follow symlinks.
Set up group ownership inheritance on newly created files:
Change the owner of the directory:
chown -R apache:apache /var/www/web
Make sure all files created within the directory are assigned permissions given to the group of the parent directory:
chmod g+s /var/www/web
Make sure the permissions assigned to new files are proper:
cd /var/www/web umask u=rwx,g=rwx,o=r
Give access to your SMB created user:
setfacl -m user:writerrobot:rwx /var/www/raweb
Remove all explicit facl entries (just rely on POSIX):
setfacl -b /var/www/raweb
Remember to consider SELinux:
Making sure the directory is tagged with public_content_rw_t is important.