Tech Mavens

Achieving More Flexible File Permissions
Using Solaris ACLs
by Ross Oliver

Published in the May, 2001 issue of Sysadmin magazine

The fixed set of UNIX file permissions for owner, group, and world is simple to understand and easy to manage. However, the simplicity of this scheme is also its most frustrating limitation. Most UNIX systems administrators have at one time or another wished for just one more set of permissions to accomplish some necessary task.

Traditional workarounds include multiple user accounts, multiple group memberships, and set-UID programs. Although these methods work, they are not ideal because they add complexity, require root access to implement, and often raise security problems.

In the Solaris world, these limitations were finally overcome with the introduction of Access Control Lists (ACLs). Introduced in Solaris 2.5, ACLs are additional sets of read/write/execute triplets that can be added on to files, directories, devices, or any other file system objects. Using ACLs, systems administrators as well as ordinary users can now fine-tune access without resorting to multiple groups or set-UID programs. This article is a practical look at how to use ACLs on a real network.

Managing ACLs

In the fine UNIX tradition, the utilities to manage ACLs have the awkward but utilitarian names getfacl and setfacl (I pronounce them GET-fakle and SET-fakle). getfacl takes file names as command-line arguments, and outputs a textual representation of all ACLs currently in place for the named files. setfacl accepts command-line options to install, modify, or remove ACLs. Here is an example of getfacl output for a file named "sample-file" that has no ACLs, only the standard UNIX permissions:

$ getacl samplefile

1. file: samplefile
2. owner: reo
3. group: sysadmin

user::rw-
group::r-- #effective:r--
mask:r--
other:r--

The user, group, and other fields correspond to the standard UNIX permission bits. The mask field works like a real-time umask, screening off unwanted access for group and other. So, if other were set to rwx, and mask set to -, the effective permissions for other would be -. To give the user tdk write permission on the above file, the setfacl command line would be:

$ setfacl -m user:tdk:rw- samplefile
$ getacl samplefile

1. file: samplefile
2. owner: reo
3. group: sysadmin

user::rw-user:
tdk:rw- #effective:r--
group::r-- #effective:r--
mask:r--
other:r--

Note the new user:tdk entry, and the #effective field, which displays the combined results of the user permissions and the mask. In this case, #effective indicates the mask must be changed for the new ACL to have the desired effect:

$ setfacl -m mask:rw- samplefile
$ getacl samplefile

1. file: samplefile
2. owner: reo
3. group: sysadmin

user::rw-user:
tdk:rw- #effective:rw-
group::r-- #effective:r--
mask:rw-
other:r--

To indicate the presence of ACLs, Sun modified the format of the ls -l command so that a "+" character is displayed immediately to the right of the standard file permissions. For the example file above, ls -l would show:

$ ls -l samplefile
-rw-rw-r--+ 1 reo sysadmin 6242 Dec 14 15:16 samplefile
Putting ACLs into Practice

Consider that Department Director Laura F. is going on a 2-week vacation to a South Pacific island that has never heard of email. Laura would like to give her deputy, James K., read-only access to her mailbox so he can monitor for any emergencies. At first, the sys admin is stumped for a solution. She cannot change the group of Laura’s mailbox file; all mailbox files must be in the "mail" group for the mail delivery agent to function properly:

$ ls -l /usr/spool/mail/lauraf
-rw-rw---- 1 laurak mail 3448683 Aug 21 12:10 /usr/spool/mail/lauraf
The sys admin also rules out making Laura’s mailbox publicly readable, as this would risk exposing sensitive information. Two other possibilities are similarly unpalatable: adding James to the "mail" group, or giving him direct access to Laura’s account. Finally, the sys admin remembers an article she read about Solaris ACLs. She uses setfacl to grant James read-only access to Laura’s mailbox file:

$ setfacl -m user:jamesk:r-- /usr/spool/mail/lauraf
$ getacl /usr/spool/mail/lauraf

1. file: /usr/spool/mail/lauraf
2. owner: lauraf
3. group: mail

user::rw-user:
jamesk:r-- #effective:r--
group::rw- #effective:rw-
mask:r--
other:r--

Thus, functionality and security are preserved, James can monitor Laura’s email, leaving the nightlong beating of native drums as Laura’s only worry.

This example illustrates one of the most useful aspects of ACLs. They provide the ability to grant access to files in situations where changing existing permissions or groups would compromise security, or disrupt the functionality of an existing application.

Default ACLs and Directories

The previous example showed how ACLs can be installed onto existing files. Is there a way to specify ACLs for files that will be created in the future? The "default" ACL serves this purpose. Default ACLs are permitted only on directories, and specify ACLs that new files will inherit when created within those directories. Here is a directory that has default ACLs:

$ getfacl sampledir

1. file: sampledir
2. owner: reo
3. group: sysadmin

user::rwx
group::r-x #effective:r-x
mask:r-x
other:r-x
default:user::r-x
default:group::r-x
default:mask:rwx
default:other:r-x
default:user:tdk:rw-

Note that getfacl still reports a type of "file" even on a directory.

When a file is created in sampledir, it will automatically receive the default ACLs from its parent directory as its user, group, mask, and other ACLs. This table shows how the default ACLs on the directory sampledir map onto files created in that directory:

ACLs on sampledir ACLs on new files created in sampledir

default:userr-x default:groupr-x

default:mask:rwx -> mask::rwx
default:other:r-x -> other::r-x
default:user:tdk:rw- -> user:tdk:rw-
Note that setfacl will not allow creation of user- or group-specific defaults (e.g., default:user:tdk:rw-) unless the directory already has the four generic defaults.

Default ACLs in Practice

The fictitious accounting firm of Dewey, Cheetam and Howe (DCH) has arranged for several clients to transmit their weekly payroll data via FTP to DCH’s Solaris FTP server. Once the data arrives, Clark, the DCH’s payroll clerk, retrieves the data files, also using FTP. Because these files contain the clients’ confidential data, the clients must be allowed to read and write only their own files. Additionally, Clark needs full access to all the client files.

Joe, the sys admin in charge of the implementation, has no trouble meeting the first requirement. He creates a separate directory and UNIX group for each client, setting the directory permissions accordingly. However, the clerk’s need for universal access poses a problem. Because newgrp won’t work with an FTP login, Joe can’t simply put the Clark’s account in all the client groups. However, by using ACLs, Joe can give Clark access to existing files in all the client directories, as well as any files created in those directories in the future.

$ mkdir client1dir
$ chgrp client1 client1dir
$ chmod 770 client1dir
$ ls -l client1dir
-rwxrwx--- 1 root client1 4096 Dec 14 15:16 client1dir

Before Joe can create any user- specific ACLs on the client1dir directory, he must first install the non-specific defaults. All four non-specific defaults (user, group, other, and mask) must be set simultaneously in one setfacl command. To make the command line more manageable, Joe takes advantage of setfacl’s recognition of single-letter abbreviations of the ACL attributes:

$ setfacl -s urwx,o:-,m:rwx,d:u

rw-,d:g

rw-,d:o:-,\

d:m:rw-clientdir

Finally, Joe adds the user-specific default ACL for Clark’s access:

$ setfacl -m default:user:clark:rw- client1dir

Here are the final permissions on the directory client1dir, as shown by getfacl:

$ getfacl client1dir

1. file: client1dir
2. owner: root
3. group: client1

user::rwx
group::rwx #effective:rwx
mask:rwx
other:---
default:user::---
default:user:clark:rw-
default:group::---
default:mask:rw-
default:other:---

The default ACL entries do not affect access to the client1dir directory itself. If Clark’s account is not a member of the client1 group, Joe will also need to add another ACL to the directory to give Clark read, write, and search access to the client1dir directory:

$ setfacl -m user:clark:rwx client1dir
$ getfacl client1dir

1. file: client1dir
2. owner: root
3. group: client1

user::rwx
user:clark:rwx #effective:rwx
group::rwx #effective:rwx
mask:rwx
other:---
default:user::---
default:user:clark:rw-
default:group::---
default:mask:rw-
default:other:---

Whenever a new file is created in the "client1dir" directory, it will have the owner and group of the creating account, but will also automatically receive an ACL allowing Clark read and write access. Joe tests this out to be sure:

$ touch client1dir/testfile
$ getfacl client1dir/testfile

1. file: client1dir/testfile
2. owner: root
3. group: client1

user::rwx
user:clark:rw- #effective:rw-
group::rw- #effective:rw-
mask:rw-other:---

Copying ACLs

It would be tedious and troublesome for Joe to repeat the above process for each client directory. Fortunately, the -f option to setfacl provides the ability to copy the entire set of ACLs from one file (or directory) onto another. The -f option tells setfacl to read ACLs from a file, in the same format as output by getfacl. The file name can be "-" to tell setfacl to read ACLs from the standard input. Thus , Joe can duplicate the ACLs from the client1dir directory onto client2dir and other subsequent directories with one simple command:

$ getfacl client1dir | setfacl -f - client2dir

More ACL Uses

ACLs are also handy in delegating selected systems administration tasks. This capability is especially useful in certain environments that prohibit the use of non-commercial tools such as sudo. For example, a common task to delegate is maintenance of the /etc/aliases file. If available, sudo can be used to permit a non-root user to invoke an editor on the /etc/aliases file. However, this could be a serious security problem. Most editors allow shell escapes and the execution of arbitrary commands, which would execute at root privilege. This would bypass sudo security. A more secure alternative would be to add an ACL to /etc/aliases to allow the user to edit the file directly, with no need for root privilege.

The fine-grained access control afforded by ACLs can be helpful to ordinary users as well. For example, Fred needs to allow Carl to access files in Fred’s home directory, but Carl is not a member in the group that owns Fred’s home directory. Without ACLs, Fred would have to make his home directory world readable and searchable for Carl to access it. However, using an ACL, Fred can grant full access to Carl alone, without opening up Fred’s home directory to everyone on the system.

Say What?

Even after so many years, UNIX programmers still have not learned how to give their programs good table manners. The ACL management utilities are no exceptions. So, here is your secret decoder card for some of the most common crypto-errors from setfacl:

setacl error: Invalid argument

Root is no longer omnipotent. Only the owner of a file or directory can add or change ACLs. If root tries to set an ACL on a non-root file, setfacl will respond with this very helpful error message.

Missing user/group owner, other, mask entry

You used the -s option, but did not include the required user, and maskr--) exist.

non-digit in id field

The user or group name in an ACL entry does not exist. If the name is not found in /etc/password or /etc/groups, setfacl will try to interpret the field as a numeric ID.

Unrecognized character found in mode field

setfacl found a character other than r, w, x, or - in the permissions field. The message itself is not so bad, but it would be much more helpful if setfacl specified which position held the incorrect character.

Some parsing errors will cause setfacl to exit without producing any error message. If setfacl is silent, but does not appear to have done what you intended, check the exit status. If it is non-zero, a parsing error may have occurred. One particular error I noticed that will cause this behavior is an extraneous colon character in certain ACLs, such as "other::rwx".

Conclusion

Access Control Lists augment the traditional UNIX file permissions scheme to permit more flexibility and fine-grained control over file access. ACLs are especially useful in situations where changing or adding groups is not possible. Systems administrators no longer need to resort to convoluted arrangements of multiple groups and set-UID scripts to achieve the best balance of utility and security. While ACLs may not be everyday tools, they are an excellent addition to every Solaris sys admin’s bag of tricks for those occasions when the standard UNIX permissions just aren’t enough.