Home > Uncategorized > Setting explicit ACLs per entity in linux

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.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: