Hack53.Refine Permissions with ACLs

Hack 53. Refine Permissions with ACLs

Access control lists bring granular permissions control to your files and directories.

Standard Unix/Linux file permissions are fine if you have a relatively small number of users with limited requirements for sharing and working on the same files. ("Share Files Using Linux Groups" [Hack #52] explained the classic approaches to enabling multiple users to work on the same files.) However, using groups to control shared access requires the intervention of a system administrator and can result in incredibly huge and complex /etc/group files. This makes it difficult to set the group memberships for any new accounts correctly and requires frequent sysadmin intervention as users leave or move between projects. ACLs, which are supported in most modern Linux distributions, eliminate this hassle by providing a fine-grained set of permissions that users can impose on their own directories, going far beyond the permissions and protections provided by standard Linux groups.

Simply put, an ACL is a list of Linux users and/or groups and the access rights that they have to a specific file or directory. ACLs enable you to define totally granular permissions such as "only the users wvh and alex can write this file, but the user juser can at least read it" without requiring that you create any special-purpose Linux groups.

ACLs as implemented on Linux systems today are defined by the draft Portable Operating System Interface (POSIX) standard 1003.1e, draft 17, from the Institute of Electrical and Electronics Engineers (IEEE). This is not an official standard, but it is publicly available and has become the foundation for ACL implementations for modern operating systems such as Linux. (See the end of this hack for pointers to this document on the Web.)

5.9.1. Installing and Activating ACL Support

To use ACLs to enhance the granularity of permissions on your system, you must have several things in place:

• Your kernel must be compiled with both enhanced attribute and ACL support for the type(s) of filesystem(s) that you are using.

• Your filesystem(s) must be mounted with extended attribute and ACL support enabled [Hack #54].

• You must install the user-space ACL utilities (chacl, getfacl, and setfacl) in order to examine and set ACLs.

5.9.1.1. Kernel ACL support.

Most modern Linux distributions provide support for ACLs in the default kernels that they deliver. If you have access to the configuration file used to build your kernel, you can use the grep utility to check to make sure that the POSIX_ACL configuration variable associated with the types of filesystems that you are using is set to y, as in the following example:

 $ grep POSIX_ACL /boot/config-2.6.8-24.16-default EXT2_FS_POSIX_ACL=y EXT3_FS_POSIX_ACL=y REISERFS_FS_POSIX_ACL=y JFS_POSIX_ACL=y XFS_POSIX_ACL=y 

If the POSIX_ACL value associated with any of the types of filesystems you are using is set to n, you will have to enable it, save the updated kernel configuration, and recompile your kernel in order to use ACLs. To enable the appropriate POSIX_ACL value, you will also have to enable extended attributes for that filesystem. Extended attributes must be separately enabled for each type of filesystem you are using (with the exception of the XFS journaling filesystem, which inherently supports them). The kernel configuration options that enable them are located on the File Systems pane in your favorite kernel configuration editor (make xconfig, make menuconfig, and so on). See "Make Files Easier to Find with Extended Attributes" [Hack #54] for more information about enabling and using extended attributes.

5.9.1.2. fstab ACL support.

Once you are running a kernel with support for POSIX ACLs, you will also need to make sure that the filesystems in which you want to use ACLs are mounted with ACL support enabled. Check your /etc/fstab file to verify this. Filesystems mounted with ACL support will have the acl keyword in the mount options portions of their entries in the file. In the following example, the reiserfs filesystem on /dev/sda6 is mounted with ACL support, while the ext3 filesystem on /dev/hda1 is not:

 /dev/sda6  /usr   reiserfs   noatime,acl,user_xattr 1 2 /dev/hda1  /opt2  ext3       defaults               0 0 

If your kernel supports ACLs, you can edit this file to enable ACL support when you initially mount a filesystem by adding the acl keyword to the mount options for that filesystem, as in the following example:

 /dev/hda1    /opt2     ext3     defaults,acl     0 0 

After updating this file, you can enable ACL support in currently mounted filesystems without rebooting by executing a command like the following, which would remount the example ext3 filesystem /dev/hda1, activating ACL support:

 # mount -o remount,acl /dev/hda1 

5.9.1.3. User-space ACL support.

The last step in using ACLs on your system is to make sure that the user-space applications that enable you to display and set ACLs are present. If your system uses a package management system, you can query that system's database to see if the acl package and its associated library, libacl, are installed. The following is an example query on a system that uses RPM:

 # rpm -qa | grep acl acl-2.2.25-2 libacl-2.2.25-2 

You can also look for the utilities themselves, using the which command:

 # which getfacl /usr/bin/getfacl # which setfacl /usr/bin/setfacl # which chacl /usr/bin/chacl 

If the acl package is not installed and the binaries are not present on your system, you can find the source code or binary packages for your system by following links from http://acl.bestbits.at. You'll need to install these packages before continuing.

5.9.2. Overview of Linux ACLs and Utilities

Linux supports two basic types of ACLs:

• ACLs used to control access to specific files and directories

• Per-directory ACLs (known as mask ACLs), which define the default ACLs that will be assigned to any files created within that directory

Conversationally and in print, ACLs are represented in a standard format consisting of three colon-separated fields:

• The first field of an ACL entry is the entry type, which can be one of the following: user (u), group (g), other (o), or mask (m).

• The second field of an ACL entry is a username, numeric UID, group name, or numeric GID, depending on the value of the first field. If this field is empty, the ACL refers to the user or group that owns the file or directory. mask and other ACLs must have an empty second field.

• The third field lists the access permissions for the ACL. These are represented in two forms:

  • A standard Unix-like permissions string or "rwx" (read, write, and execute permissions, where execute permissions on directories indicate the ability to search those directories). Each letter may be replaced by a dash (-), indicating that no access of that type is permitted. These three permissions must appear in this order.

  • A relative symbolic form that is preceded by a plus sign (+) or a caret symbol (^), much like the symbolic permissions that are designed for use with the chmod command by people who are octally challenged. In this ACL representation, the + or ^ symbols are followed by single r, w, or x permission characters, indicating that these permissions should be added to the current set for a file or directory (+) or removed from the current set (^) for a given file or directory.

When listed or stored in files, different ACL entries are separated by white space or new lines. Everything after a # character to the end of a line is considered a comment and is ignored.

The Linux acl package provides the following three utilities for ACL creation, modification, and examination:

chacl

Lets you change, examine, or remove user, group, mask,or other ACLs on files or directories

getfacl

Lets you examine file ACLs for files and directories

setfacl

Lets you set file and directory ACLs

5.9.3. Displaying Current ACLs

As an example of using ACLs, let's use a directory with the following contents and permissions:

 $ ls -al total 49 drwxr-xr-x 2 wvh users 80 2005-07-04 13:59 . drwxr-xr-x 106 wvh users 5288 2005-07-04 14:47 .. -rw-r-----1 wvh users 44032 2005-07-04 13:58 resume.xml 

The default ACL for this directory is the following:

 $ getfacl . # file: . # owner: wvh # group: users user::rwx group::r-x other::r-x 

The default ACL for the file resume.xml is the following:

 $ getfacl resume.xml # file: resume.xml # owner: wvh # group: users user::rw- group::r-- other::--- 

The default ACL for a file in a directory for which a default ACL has not been set reflects the default Unix permissions associated with the user that created the file. The default Unix permissions for a file are based on the setting of the umask environment variable [Hack #52].

5.9.4. Setting ACLs

There are three common ways to change the ACL of a file or directory:

• By setting it explicitly using the setfacl command, which overwrites any existing ACL settings

• By using the setfacl command with the -m (modify) option to modify an existing ACL

• By using the chacl command to modify an existing ACL

For the examples in this hack, I'll use the chacl command to change ACLs, since this doesn't overwrite the existing ACL. It also provides a bit more information about how ACLs really work than the shorthand version of the setfacl command.

For example, to add the user alex as someone who can read the file resume.xml, I would use a chacl (change ACL) command like the following:

 $ chacl u::rw-,g::r--,o::---,u:alex:r--,m::rw- resume.xml 

No, that isn't static from a bad modem or Internet connection (though it probably is a command in the old TECO editor)that's the way ACLs look in real life. As mentioned previously, ACLs consist of three colon-separated fields that represent the permissions of the user (the owner of the file), group (the group ownership of the file), and others. When changing an ACL with the chacl command, you need to first specify the ACL of the file and then append the changes that you want to make to that ACL. The u::rw-,g::r--,o::--- portion of the ACL in this example is the existing ACL of the file; the u:alex:r--,m::rw- portion specifies the new user that I want to add to the ACL for that file and the effective rights mask to be used when adding that user. The effective rights mask is the union of all of the existing user, group, and other permissions for a file or directory. You must specify a mask when adding a random user to the ACL for a file.

Using the getfacl command to retrieve the ACL for my resume shows that the user alex has indeed been added to the list of people who have access to the file:

 $ getfacl resume.xml # file: resume.xml # owner: wvh # group: wvh user::rwx group::r-- other::--- user:alex:r-- mask::rw- 

Though the content is the same, the format of the output of the getfacl command depends on the version of the ACL suite that is being used on your Linux system.

Using the ls -al command shows that the visible, standard Unix file and directory permissions haven't changed:

 $ ls -al total 49 drwxr-xr-x 2 wvh users 80 2005-07-04 13:59 . drwxr-xr-x 106 wvh users 5288 2005-07-04 14:47 .. -rw-r-----1 wvh users 44032 2005-07-04 13:58 resume.xml 

You can verify that the user alex now has access to the file by asking him to attempt to read the file. (If you know his password, you can check this yourself by su'ing to that user or by connecting to your machine over the network, logging in as alex, and examining the file using a text editor or a command such as more or cat.)

Even more interesting and useful than just giving specific individuals read access to files is the ability to give specific users the ability to write to specific files. For example, to add the user alex as someone who can both read and write to the file resume.xml, I would use a chacl command like the following:

 $ chacl u::rw-,g::r--,o::---,u:alex:rw-,m::rw- resume.xml 

Using the getfacl command shows that the user alex now has both read and write access to the file:

 $ getfacl resume.xml # file: resume.xml # owner: wvh # group: users user::rw- group::rw- other::--- user:alex:rw- mask::rw- 

As before, you can verify that the user alex now has both read and write access to the file by asking him to attempt to read and write to the file. (If you know the test user's password, you can check this yourself by connecting to your machine over the network, logging in as that user, and editing and saving the file using a text editor.)

I'm a big fan of ACLs, primarily because they give knowledgeable users total control over who can access their files and directories. ACLs remove one of the main administrative complaints about Unix systems: the need for root access to set up granular permissions. As a fringe benefit, they also silence one more argument for using systems such as Windows 2000/2003/XP.

5.9.5. See Also

• "Share Files Using Linux Groups" [Hack #52]

• "Make Files Easier to Find with Extended Attributes" [Hack #54]

• POSIX.1e draft specification: http://wt.xpilot.org/publications/posix.1e

• POSIX ACLs on Linux: http://www.suse.de/~agruen/acl/linux-acls/online