Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 39 Next »

Introduction

What are ACLs?

ACLs versus Traditional Permissions

ACLs though powerful add additional complexity to the system and do have some limitations discussed further down this article. You will notice throughout the Bonsai Framework we add ACLs only when absolutely necessary.

Limitations

Support in Utilities - For example, the version of GNU tar packaged with the OS may not back up or restore ACLs.

Standardizing Across Operating Systems - Moving files with ACLs between operating systems that both support ACLs may not work.

Move - Moving a file created outside of an ACL directory into an ACL directory will not result in inheritance of permissions. (even with defaults set)

Backup - The most used backup command in *nix, tar, does not support ACLs unless modified. Some distributions like redhat have this built into tar. Otherwise your options are to use star or manually backup and restore the ACLs. Options are covered in this article.

Copying Files - This is no-longer an issue with modern (2012 is when I checked) versions of Ubuntu and I would guess other *nix systems. If you want to preserve specific ACL permissions and not inherit, use -p. With an older system, check that when setting default ACLs on a directory, the following commands will inherit permissions properly:  local copy, sftp remote create and sftp remote copy.

SFTP - copy/create will inherit ACLs, but move from outside needs to be tested.

Creating Users and Groups

sudo --gid 3100 dailyplanet
sudo --gid 3101 lexcorp
sudo useradd -d /opt/web/php/ckent -m -g wgdailyplanet -u 4001 -c "Clark Kent" -s /bin/bash ckent
sudo useradd -d /opt/web/php/lluthor -m -g wglexcorp -u 4005 -c "Lex Luthor" -s /bin/bash lluthor

 

ACLs and Groups

The most scalable way to use ACLs is to apply groups. A tutorial approach will be used to illustrate the commands.

The scenario is we want to provide website hosting for two different clients who we will start by categorizing into two different groups,

UserGroupWeb DirectoryFile AccessDirectory Access
Daily Planet Employeeswgdailyplanet/opt/web/php/dailyplanet/Read, Write and ExecuteRead, Write and Execute
LexCorp Employeeswglexcorp/opt/web/php/lexcorp/Read, Write and ExecuteRead, Write and Execute
Apache Serverwww-data/opt/web/php/dailyplanet/
/opt/web/php/lexcorp/
ReadRead and Execute (required to transverse directories)
Staff Usersstaff

/opt/web/php/dailyplanet/
/opt/web/php/lexcorp/

ReadRead and Execute (required to transverse directories)
Other  No AccessNo Access

We do not want employees from different companies access or even have awareness of each others web directory. At the same time, the Apache Server running as user www-data belonging to group www-data also needs access to the directories. We also want to grant users of the staff group read access for support purposes.

Creating the Directory Structure

 

The utility setfacl is used to add the groups to the ACL for the respective directories,

Take a look at the ACLs,

cd /opt/web/php/
# Normal permissions
sudo chmod -R o-rwx ./dailyplanet/
# ACL permissions
sudo setfacl -Rm g:wgdailyplanet:rwX ./dailyplanet/
sudo setfacl -Rm g:www-data:rX ./dailyplanet/
sudo setfacl -Rm g:staff:rX ./dailyplanet/
getfacl ./dailyplanet/
# file: www.dailyplanet.com
# owner: ckent
# group: wgdailyplanet
user::rwx
group::r-x
group:www-data:r-x
group:staff:r-x #staff is given access in case users belonging to the virtual hosts make files and try to hide them for comprimising the system
group:wgdailyplanet:rwx
mask::rwx
other::---

Don't be alarmed that you see x on the groups www-data, staff and wgdailyplanet. That is normal *nix convention it means that execute permission will only be applied on directories. Files will be default not have execute permission applied.

Once we are happy with the permissions, change the default ACLs so any files or folders created underneath the parent directories are maintained.

Look at the default ACLs,

getfacl --default ./dailyplanet/
# file: www.dailyplanet/
# owner: ckent
# group: wgdailyplanet

Apply changes to the default ACLs,

getfacl --access ./dailyplanet/ | sudo setfacl -d -RM - ./dailyplanet/

getfacl --access =  retrieves the ACL the permissions applied to the directory only (default permissions are not returned). The details are then piped to setfacl and the parameters read,

-d = Change default permissions for newly created files and folder.
-M = Take as input files. Because the dash is used, the file is instead standard input.
R  = Apply changes recursively to folders and files.

The default ACLs should now be changed,

getfacl --default ./dailyplanet/
# file: www.dailyplanet/
# owner: ckent
# group: wgdailyplanet
user::rwx
group::r-x
group:www-data:r-x
group:staff:r-x
group:wgdailyplanet:rwx
mask::rwx
other::---

If you want to see what the applied and default look like dont specify

getfacl ./dailyplanet/
# file: www.dailyplanet/
# owner: ckent
# group: wgdailyplanet
user::rwx
group::r-x
group:www-data:r-x
group:staff:r-x
group:wgdailyplanet:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:www-data:r-x
default:group:staff:r-x
default:group:wgdailyplanet:rwx
default:mask::rwx
default:other::---

 

Repeat the same steps for www.lexcorp.com and change the group accordingly,

cd /opt/web/php/
# Normal permissions
sudo chmod -R o-rwx ./lexcorp/
# ACL permissions
sudo setfacl -Rm g:wglexcorp:rwX ./lexcorp/
sudo setfacl -Rm g:www-data:rX ./lexcorp/
sudo setfacl -Rm g:staff:rX ./lexcorp/
# Apply default ACLs
getfacl --access ./lexcorp/ | sudo setfacl -d -RM - ./lexcorp/

Testing Restrictions

User Lex Luthor has been given access to his directory "lexcorp" but learns of the "dailyplanet" directory by using his robots to spy on Clark Kent's computer. So Lex terminals in...

cd /opt/web/php/
cd dailyplanet
-su: cd: dailyplanet: Permission denied

After failing to enter dailyplanet he enters his own directory lexcorp and creates a directory to keep his evil plan.

cd /opt/web/php/lexcorp
mkdir secrets
chmod 700 secrets
cd secrets
ne evil plan
chmod 700 secrets

 

Backup and Restore

Introduction

The current (September 2012) GNU version of TAR does not support ACLs without modifications.

As with any backup and restore scenario where user based permissions matter, make sure the users actually exist and match. To ensure you have no issues, also ensure consistent use of user and group UIDs.

Backup

ACLs permissions can be backed up to a text file,

sudo getfacl -R dailyplanet/ > ~/dailyplanet.acl.bck.txt

It is important to run getfacl with sudo so that getfacl can properly transverse the directories and owner comments or group comments will be retained.

Backup the files into tar and gzip or similar program,

# consider command what will also drop in the acl.bck file.

Restore

Uncompress the backup, in this case we used the tar with gunzip,

....

Restoring ACLs

Restoring is a pretty straightforward process.

cd /opt/web/php/
sudo setfacl --restore ./bck.dailyplanet.acl.bck.txt

References

Good introduction from the Ubuntu docs - https://help.ubuntu/community/FilePermissionsACLs

Slightly Skeptical view on ACLs - http://softpanorama.org/Articles/slightly_skeptical_view_on_unix_acl.shtml

Got me to understand why execute permission was set on the groups - http://superuser/questions/180545/setting-differing-acls-on-directories-and-files

Notes on backup and restoring ACLs using dump file - http://projectenvision/blog/4/Enable-Support-for-ACL-in-Debian-Ubuntu

Good article on masks - http://novell/documentation/suse91/suselinux-adminguide/html/apbs03.html

  • No labels