(?) The Answer Gang (!)


By James T. Dennis, [email protected]
LinuxCare, http://www.linuxcare.com/


(?) ACLs on Linux

In reply to Ivan Sergio Borgonovo on the SVLUG list

Answered By: Rick Moen

I thought you might be interested in the thing that follows, because of what I've heard you say in the past about capabilities models.

Jim Dennis has been quite verbose about the difference between the current Linux privileges model and true capabilities systems like EROS (eros-os.org). -- Heather

(?) A guy posting to the SVLUG list from Italy, Ivan Sergio Borgonovo, asked whether there were any general summaries of ACLs on Linux.

(!) I looked around, was astonished to find that there weren't any, and decided to write one. It follows -- used within VA Linux's Knowledgebase, now, but I see no reason it can't be used anywhere else, as well. I hope you'll find it of interest.

And so, it's posted here for all of you, dear readers. -- Heather

(?) 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 (August 2000), 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.transarc.com/Product/EFS/AFS) or the Arla Project (http://www.stacken.kth.se/projekt/arla), GFS (http://www.globalfilesystem.org), or ReiserFS (http://devlinux.com/projects/reiserfs).
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://www.guug.de/~winni/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.
The pre-existing Linux AFS project, the 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://www.rzuser.uni-heidelberg.de/~x42/linuxafs/linuxafs.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 aims for Samba to directly support POSIX ACLs on Linux if they are ever incorporated into the standard Linux kernel source tree: http://info.ccone.at/INF (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 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 .


Copyright © 2000, James T. Dennis
Published in the Linux Gazette Issue 57 September 2000
HTML transformation by Heather Stern of Tuxtops, Inc., http://www.tuxtops.com/


[ Answer Guy Current Index ] greetings   1   2   3   4   5   6   7 [ Index of Past Answers ]