Q: Is there support for ACLs (Access Control Lists) in Linux?

A: Yes, there is — from multiple development projects, with divergent approaches, all aiming to allow the administrator some means of specifying what capabilities a process is to be allowed, and other fine-grained permissions (including Mandatory Access Control labels, Capabilities, and auditing information). At this time (May 2001), all require modifications (third-party, unofficial kernel patches) to the Linux kernel's filesystem and VFS code (umask and access-control modifications), which sometimes take a while to catch up with new kernel releases. The kernel maintainers have not endorsed any one approach. Thus, implementing any of these approaches remains an advanced topic using experimental code.

Further, there is not broad agreement on what filesystem it is best to use with ACLs. The obvious choices are ext2 + extended-attributes extensions, Steven Tweedie's ext3 (ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs/), the AFS implementations from IBM/Transarc (http://www.openafs.org/) or the Arla Project (http://www.stacken.kth.se/projekt/arla/), GFS (http://www.globalfilesystem.org/), SGI's XFS (http://linux-xfs.sgi.com/projects/xfs/), or ReiserFS (http://www.namesys.com/).

Adding further confusion is that the leading candidate for an ACL standard, IEEE Std 1003.1e, was withdrawn by the IEEE/PASC/SEC working group while it was still a draft, on Jan. 15, 1998, and thus was never formally included in POSIX (http://wt.xpilot.org/publications/posix.1e/). It nonetheless remains influential.

Generic "capabilities" support is included in 2.2 and greater kernels, including a control in /proc called the "capabilities bounding set". Many "capabilities" operations will also require libcap, a library for getting and setting POSIX 1003.1e-type capabilities, which you can find at ftp://ftp.de.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/ . See also the Linux Kernel Capabilities FAQ: ftp://ftp.de.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt .

The VFS patches, filesystems extensions or other filesystem facilities to store ACLs, patches for fsck utilities (preventing them from "cleaning up" your extended attributes), patches for GNU fileutils, patches for the quota tools, and administrative tools must be provided by the various unofficial ACL-on-Linux projects, of which there are several.

In addition to applying any applicable patches to your kernel, you will have to enable three kernel-configuration options (all in the "filesystems" section): "Extended filesystem attributes" (CONFIG_FS_EXT_ATTR), "Access Control Lists" (CONFIG_FS_POSIX_ACL) and "Extended attributes for ext2" (CONFIG_EXT2_FS_EXT_ATTR). In order to be offered these configuration options, you must also select "Prompt for development and/or incomplete code/drivers" (CONFIG_EXPERIMENTAL) in the code-maturity level options, towards the beginning of kernel configuration.

The AFS distributed storage system, originally developed at CMU, generically has built-in support for ACLs. As such, it seems reasonable to suspect that IBM/Transarc's leading AFS implementation on Linux, due to have an open-source (GPLed) development fork on the near future, would include ACL support. We have been unable to confirm that from Transarc's documentation, thus far. This may change as Transarc completes its open-source rollout. (Unfortunately, Transarc's open-source fork will have a licence problem that will prevent it shipping with Linux-based systems: It will be issued under the IBM Public Licence, which, although open source, is not compatible with the GNU General Public Licence the Linux kernel is issued under.)

The pre-existing Linux AFS project, the GPL-licenced Arla Project, has reportedly been moving slowly. The quality of its ACL support is likewise unknown.

The existing documentation for AFS on Linux, unfortunately, makes no mention of ACLs or capabilities support: http://sarn.org/docs/linux-afs/faq.html http://web.urz.uni-heidelberg.de/Veranstaltungen/LUG/Vortraege/AFS/AFS-HOWTO.html

There have been two main attempts to implement POSIX ACLs on ext2 + extensions. One was the LiVE Project, at http://aerobee.informatik.uni-bremen.de/acl_eng.html . That effort appears to be now defunct.

The other, and probably your best bet for ACLs on Linux today, is Andreas Gruenbacher's Linux ACLs project, http://acl.bestbits.at/ . Gruenbacher has a well-developed ACL implementation with storage extensions for ext2, linking the extended attributes to inodes, and with ACLs among the data storable in those extended attributes. He expects that porting his subsystem to ext3 will be easy.

The Samba Project favours/encourages Gruenbacher's approach, and as of April 2001, Samba 2.2 will support his ACLs implmentation, if supported in the Linux kernel. (See: http://lists.samba.org/archive/samba-technical/2000-April/007619.html , http://us1.samba.org/samba/whatsnew/samba-2.2.0.html .)

The Linux Trustees Project (http://trustees.sourceforge.net/) is a non-POSIX, memory-based approach, loading all extended-attributes information from a database at startup.

RSBAC (http://www.rsbac.de/) is another Linux project to implement non-POSIX ACLs, along with a number of other security-architecture goals.

Linux-Privs (http://sourceforge.net/projects/linux-privs/) is a project to implement the entire POSIX draft on Linux, and has moved slowly but is cooperating with Gruenbacher, resulting in part in these patches/utilities for 2.2.x and 2.4.x kernels by Linux kernel programmer Andrew G. Morgan (with some code by Gruenbacher): ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/

The ReiserFS and GFS maintainers are aware of the desirability of adding extended-attribute support to their filesystems, but have not yet done so. Hans Reiser is believed to favour a system implementing Macintosh-style resource streams/forks of artbitrary length to store the extended information, rather than extended-attribute storage within the filesystem structure.

Andreas Dilger has spoken of the Intermezzo distributed file system project (http://www.inter-mezzo.org/) in the near future implementing extended attributes similar to Gruenbacher's, making future ACL support on that filesystem (which is still in early beta) likely.

The XFS filesystem maintainers have built in full support for POSIX ACLs.

The LIDS Project (http://www.lids.org/) implements some "capabilities" ideas, but not ACLs.

Last, Pavel Machek maintains an "ELF capabilities" kernel patch and matching utilities, which allow the admin to strip specified capabilities from binary executables at execution time. It does not provide other ACL-type capabilities. The information on what capabilities to drop for a given binary upon execution is stored inside the ELF header, in a manner compatible with ordinary Linux operation. The advantage to this approach is that it does not require extended-attributes support in the underlying filesystem. Full details are at http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html