Achieving More Flexible File Permissions Using Solaris ACLs

Ross Oliver

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 "samplefile" that has no ACLs, only the standard UNIX permissions:

$ getacl samplefile
# file: samplefile
# owner: reo
# 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.