Department of Electrical Engineering and Computer Science



Linux/POSIX ACLs

This is meant to be a primer on how to use Linux/POSIX (hereafter referred to as POSIX) ACLs. For complete information on POSIX ACLs, you should refer to the following man pages: setfacl(1), getfacl(1), and acl(5) (i.e. run the command man 1 getfacl or man 5 acl, though usually you can drop the number, e.g. man getfacl). In brief an ACL (or Access Control List) is a mechanism by which one can specify old-style POSIX permissions on a per-user or per-group basis.

ACLs are relevant, partly because traditional POSIX permissions, for example, don't allow you to change the owner of a file to anyone but yourself (and you can't change the owner of files you don't own!), nor does it let you set the group-ownership of a file, unless you're a member of the group.

An example where this would be useful is creating a protected web directory in your webhome folder (~/webhome or the old CS style ~/www-home). Previously, in order to make sure that the web server could read the protected area, but others could not, we (the IT Staff) would have to chgrp (run man chgrp) the file(s) to have the webserver's group owning the files. Now, anyone can make their files readable to the webserver, and not readable to anyone else.

Though I won't go into the details, another place where this would be useful is in a shared revision-control system (such as subversion or git) or a shared research area (mounted on /research in Linux).

Terminology

ACLs use mostly the same terminology as traditional POSIX permissions; the only real difference is that there can be multiple "user" or "group" entries, each with the usual permissions (read, write, execute). For example, you could set an executable script to be group-readable, and then specify a few individual users who can execute it (and perhaps others that can write to it).

The only term that really needs to be explained here is the default ACL. When an entry is created in the default ACL on a directory, it propagates to files created beneath that directory; note that one cannot set a default ACL on a regular file. Also, setting the default ACL on the top-level folder does NOT set the actual permissions for that directory, only those created beneath it. You'll need to explicitly set the ACL entries at the top-most level.

Usage

getfacl

usage: getfacl [options] {file}

file is any file or directory. This will show you all ACL entries associated with the file (including the default ACL). There are only three options that will probably be commonly used:

setfacl

This command is somewhat more complicated than getfacl. We'll begin with setting (or resetting) ACL entries but remember there are more ways to use this command than what is described here. See the man page for more details (man setfacl).

Setting Permissions

usage: setfacl [generic options] {-m user:username:permissions} {file1 [file2 ...]}
usage: setfacl [generic options] {-m group:groupname:permissions} {file1 [file2 ...]}

username above is a named user, such as bburke, berry, tomsovic, or wrhodes, and groupname is a named group such as analog, milcluster, or isis. permissions are symbolic permissions, as also used by chmod (man chmod, used to set "traditional" POSIX file permissions). These are

For example, to give user amspay read access to a file you own:

$ touch something
$ getfacl something
# file: something
# owner: bburke
# group: itstaff
user::rw-
group::---
other::---
$ setfacl -m user:amspay:r something
$ getfacl something
# file: something
# owner: bburke
# group: itstaff
user::rw-
user:amspay:r--
group::---
mask::r--
other::---

Removing ACL Entries

Simply enough, the format is close to the same as above, you just omit the permissions field, and specify -x instead of -m. For example, to remove the permissions of user amspay from the file something above:

$ setfacl -x user:amspay something
$ getfacl something
# file: something
# owner: bburke
# group: itstaff
user::rw-
group::---
other::---

Other Options

Other Thoughts

To create a shared subversion repository, you might create the directory that would house the repository, then use setfacl to give user1 read/write/execute permissions on the directory. Then you could use it again to give user1 the same permissions in the directory's default ACL. Once that's done, use svnadmin to create the repository, and user1 will have access to it.

There are obviously more uses for this, but these are probably some of the most common. Remember, when it comes to learning how to use commands like this, nothing can substitute for use (practice/trial-and-error) and the man pages.

Related Links


 

The University of Tennessee, Knoxville. Big Orange. Big Ideas.

Knoxville, Tennessee 37996 | 865-974-1000
The flagship campus of the University of Tennessee System