Linux’s venerable file and user permissions system is solid and dependable, but not very flexible, unfortunately. For users to share access to a particular document or resource, they must all be in the same group. It’s an all-or-nothing deal, as all users within a group have all the same rights, which is most inconvenient when you wish to exclude someone, or include someone only on a limited basis.
Plus it’s tedious to create a new group simply to share a document, printer, or directory. In time, you can end up with zillions of groups and no idea of what is going on, which, as many admins can attest to, inevitably results in turning to drink and life quickly going to heck in a handbasket.
ACLs – An Alternative to Alcohol
All hope is not lost, though, as help is on the way in the form of access control lists, which Linux finally supports. This is not a trivial undertaking, as it is fundamental to kernel and filesystem architectures. ACLs have been a part of Windows and Novell Netware since forever. (Netware’s implementation is by far the best; Novell admins have extremely flexible and fine-grained control of users and resources. If money is no object, Netware is easily the network operating system of choice.)
Once again our valiant Linux programmers come through, hurrah. ACLs are supported in all the major Linux filesystems — ext2, ext3, XFS, ReiserFS, and JFS (begin ritual debate over which filesystem is best). ACLs on Linux are still bleeding-edge, though, with the major distributions just beginning to include them.
As far as I know, only SuSE is currently shipping with ACLs enabled, but things move quickly in Linux-land, so expect your favorite distribution to include them soon. ACL support has been included in the 2.5 kernel development tree; the time is not far off when it will be a standard feature. Best of all, ACLs and traditional Linux permissions can live together nicely on the same system. No need to worry about conflicts; instead sit back and enjoy the additional flexibility.
EAs, or extended attributes, are not part of a file’s data, but are instead used to define meta-data (see, now you have a legitimate reason to use this darling new buzzword). Meta-data is simply data that describes other data. It’s not the data itself, but rather labels and tags that enable cataloguing and manipulating of the actual data. Obviously, EAs are useful in many ways, not just for ACLs. ACLs are but one type of EA.
EAs are name-value pairs, completely arbitrary and user-defined. Examples include: Version 2; Author Carla; Sekkrit_level 5; Color puce — anything at all that will help you manage your files.
The command setfattr is used to create EAs. getfattr is not a personal comment, but rather a command to display the current EAs of a file. Here is a (rather unimaginative) example:
# setfattr -n Author -v Carla /etc/configfile -n NumericID -v 1001 /etc/configfile
# getfattr -d /etc/configfile
An Access Control Entry, ACE, is an individual entry in an ACL. setfacl creates an ACL, while getfacl displays one.
# setfacl -m u:fred:rw /etc/configfile
# getfacl /etc/configfile
At a minimum, an ACL must have three attributes: an entry type, either group or user; a groupname or username, or numeric ID; and the access permissions, which are the usual read/write/execute. These three attributes must always be present, and only one of each can be defined per ACL.
Default ACLs can be set on directories so that all files created in the directory will inherit the directory’s attributes:
# setfacl -m u:fred:rw,d:u:fred:rw /etc/subdir
Groups can have default attributes:
# cd /home/groupname_shared
# setfacl -m u:fred:rw,d:g:groupname:rw
Using ACLs Now
No need to deprive yourself of the pleasure of deploying ACLs now. Simply do a download and install, and away you go.
Well, except it’s not exactly simple. Installing it means downloading kernel patches and a number of utilities. Instructions, binaries, and tarballs are available at http://acl.bestbits.at/steps.html. Debian users will find nice debs for everything; use the Debian package search page to find them all. I would limit using ACLs to a test system for now. There are several gotchas, though, including:
- A lack of application support. It is possible to use ACLs to manage access to files, printers, and all your system goodies very nicely, but standard Linux file utilities have not caught up yet and do not support ACLs.
- XFS and JFS performance is bumpy.
- Backups and restores – GNU tar or dump will lose all of your nice ACL bits. But fear not, for the official ACL website, http://acl.bestbits.at/, introduces Star.
Star of the Show
Star (pronounced Ess- tar), the “standard tape archiver,” is written by uber-geek Joerg Schilling, author of cdrecord and other fine Unix utilities. Star is one heck of a great program — it’s fast, supports all tar formats, allows extraction of selected files from archives, has multi-volume
support…its list of tasty goodies goes on and on.
Replace moldy old GNU tar with it; you won’t be sorry. And best of all, it supports ACLs. Be sure to use the -acl option, or it won’t save ACL bits. To get Star, visit http://acl.bestbits.at/star.html. Study the man page! Don’t try to use Star without it; this is not your granny’s tar.
NFS support is not yet complete, but is in progress in version 4. Do not use ACLs on NFS mounts until it is completely supported or your file permissions will get all goobered up.
The Samba team, with great foresight, long ago prepared Samba to be ready when ACLs were implemented in Linux. Samba currently maps Windows ACL attributes to standard Unix permissions. When ACLs are fully implemented in Linux, you won’t need to do a thing to Samba — it’ll be ready to go.
The bottom line is that access control lists in Linux are almost ready for prime-time. Beat the rush and start testing now.