Using ACLs for Advanced File and Directory Permissions in Debian

Hello,

We often find ourselves working in directories where multiple users “clash” with one another.

A common example is when we need to clear caches generated by web server components. We then run into ownership and permission issues.

Usually, we rely on “bad good solutions”, such as:

• Adding our user to a group it doesn’t truly belong to.
• Creating custom sudo rules (which often end up being too broad, creating a significant security loophole).

Managing ACLs in Debian allows us to handle this very simply.

Understanding ACLs (Access Control Lists)

#

ACLs are an extension of standard Linux permissions (Owner / Group / Others).

They allow us to assign custom rights to multiple users or groups on a single directory or file.

Specifically, ACLs allow us to:

• Grant rwx access to another user or group without changing the file or directory owner;
• Define rules that will automatically apply to all future files created within a directory.

It is an extremely useful tool for allowing users and groups to coexist cleanly, without forcing them into the same groups or granting excessive privileges.

My rsync-based Workflows

#

I rely on lots of simple and efficient rsync-based workflows to update servers.

rsync uploads files to the server using my non-privileged user. Everything works perfectly until I need to interact with files or directories that my user doesn’t own.

It gets tricky when I want to delete a cache written by a server component, for instance, using:

1

ssh my-ssh-alias "rm -rf /var/www/html/var/cache/*"

The Solution: ACLs (Access Control Lists)

#

ACLs allow us to add rules on a case-by-case basis within our server’s directory structure.

The idea is very simple: tell the system:

“Regardless of who creates a file here, both users user and www-data have full rights over it.”

We perform the setup in administrator mode (root or similar).

First, we apply the rights to existing files and directories:

1

setfacl -R -m u:www-data:rwx,u:user:rwx /path/to/our/site/var

Then, we define default rights for all future files and folders created inside these directories:

1

setfacl -dR -m u:www-data:rwx,u:user:rwx /path/to/our/site/var

Result

#

When my template engine (Twig, to name one) generates a cache file, that file receives ACL attributes in addition to standard permissions.

This allows my user user to clear the cache created by the engine (which uses the www-data account) without:

• Being part of the corresponding group.
• Having privileges I don’t want to grant.

My deployment and/or automated cleanup scripts can now perform all necessary tasks without getting stuck on permission errors.

This is a simple, clean, and robust technique to keep a server organized without mixing everything up or sacrificing security.

How to Check if ACLs are Active?

#

When we run ls -l, we can spot a small + sign right after the traditional permission strings. For example:

1
2
3

ls -l

drwxrwxr-x+ 2 user www-data 4096 May  9 10:30 var

The + indicates that an ACL is attached to this directory.

To view the specific ACL details, we use the getfacl command:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

getfacl /path/to/your/site/var

# file: var/
# owner: user
# group: www-data
user::rwx
user:www-data:rwx
user:user:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:www-data:rwx
default:user:user:rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Warnings

#

Standard permission rules still apply to directories and files, and to users and groups not specified in the ACL.

Once ACLs are in place, some behaviors we are used to in the “world before” might change regarding how chmod commands and standard rights (Owner / Group / Others) are interpreted.

I am intentionally not going into detail here.

Cheers,

Marc JESTIN
https://marcjestin.fr