One of the major criticisms of Linux (and other *nix-like operating systems) is that the security model used to limit access to file system objects is, well, a little long in the tooth. While I think that the model has held up pretty well, I do admit that the gyrations that it puts me through can be irritating.

For those unfamiliar, the security model is quite simple (which is both its beauty and its weakness). Access to a file system object can be controlled within three categories of users: the owner of the object, the group that owns the object, and anyone who is an authorized user of the system, sometimes called "world privileges." Any of those three categories can be given authority to read, write, and execute (manage) objects. This should be familiar to anyone who has used the Qshell or qp2term interface on the i5 to manipulate objects that reside in the IFS. While this security model has worked quite well for the decades that Unix has been in existence, its a real pain in the butt for an administrator. Creating the means for users to easily share files can be particularly cumbersome and time-consuming, generally requiring an administrator to cluster users into groups and then make sure that the permissions on the directories or objects are suitably set.

Manipulating IFS object permissions from the i5/OS side not only is much simpler than from Qshell, but also yields much more flexible and finer-grained security. From the WRKAUT command (or if you're a GUI type, the OpsNav interface), you can grant or prohibit access using the same owner/group and world basis, as in the Qshell interface, but you can go much deeper and assign access privileges to objects down to a per-user basis. What many Linux users may not know is that Linux has similar capabilities, called access control lists (ACLs). This month, we'll look at Linux ACLs and learn how to put them to use at your installation.

Turning On

While most Linux distributions support ACLs, most do not have them enabled by default. Fortunately, the effort you need to put forth to activate ACLs is minimal. First, you need to ensure that your distribution has ACL support. Perhaps the easiest way to accomplish this is to issue the command getfacl. from a command line. If you get a response that looks something like this, it's likely that you have ACL support:

Why do I say "likely"? It's because I doubt that any distribution that doesn't support ACLs would have one of the programs used for manipulating them. There are more distribution-specific means to check for ACL support, but I'll leave you to the documentation for that.

Having determined that your system supports ACLs, you then need to ensure that you have a properly partitioned system. By that I mean one that has the directory (or directories) for which you want ACL support separated from the system root directory. If you issue the command mount and see something like this, you may want to reconsider experimenting with ACLs.:

(Note that the only partition listed actually containing disk space is the system root, '/').

It's not that you can't use ACLs on a system configured with one large partition. It's just that the potential to misconfigure your permissions such that you expose yourself to security or operational issues is just too great.

What you want to see is something like this:

Here, I edited out the superfluous entries shown earlier to make the list shorter. Note that I now have two partitions, one containing the system root and one hosting the '/home' directory, the typical partition for storing users' data.

Turning on ACLs is truly a simple task. You may do so in one of two ways. The first is to edit the file '/etc/fstab' and indicate that you want ACL support. In my case, that means changing this line

to this:

The next time you start your system, ACL support will be enabled. To enable it immediately, simply issue the command mount -o remount /home. If you want to enable ACL support without editing the file (requiring you to manually enable support after every system restart), then issue the command mount -o remount,acl /home.

Once you have restarted or remounted the file system, you should be able to issue the mount command with no parameters and see something similar to this:

If you do, you're ready to start assigning permissions.

ACL User-Space Tools

To make this discussion easier, consider the following scenario: Your two co-workers, Dick and Jane, are going to collaborate with you on a project. It is imperative that you have a single directory that is accessible by all three of you. Normally, you'd need to contact the system administrator for her assistance in setting this up. Traditionally, she'd create a new group and make you all members. Then, she'd set up a directory and set the directory's owner to the new group, followed by turning on the "sticky" bit (which makes the directory's owner the owner for all objects created within it). That way, any of the three of you would be able to access any file in the directory, regardless of who created it.

The problem with this scenario is that the system administrator must become involved, which may or may not be a stumbling block for you. Using ACL tools, you are able to take care of this issue yourself without the sysadmin either caring or knowing what you are doing. Since you're the project lead, you decide to create a subdirectory of your home directory, which you call "trinity." Here are the commands you issued:

As you can see, "you' is the user who owns the object (third column) and the "you' group has read,write,and execute permissions (fourth column) on this newly created directory. (Traditional Unix has a group called "users" to which all system users are assigned. Red Hat, among others, takes a different tack; they create a group per-user name. The reason is for enhanced security, since it's less likely that you'll inadvertently open up private objects to every user on your system!)

The two basic commands for managing ACLs are setfacl and getfacl. As you can guess, the former is to set them and the latter is to retrieve them. Let's see what getfacl says about our new directory:

You'll note that it's the same information as from the ls command, just in a more verbose format.

Having created the directory, you'll now add ACL information to allow your cohorts to access the files. While you're at it, you set the default ACL, which files created within the "trinity" directory will inherit:

Notice the plus sign in the output of the ls command; this indicates that there are ACLs applied to the directory. The getfacl command shows that you have the desired settings. You give Dick a call on the phone and ask him to create a file in that directory. He sees this:

What's wrong? While Dick has permission to the trinity directory, he doesn't have it to your home directory (/home/you), thus he can't look at anything below your home directory. You fix that for him and Jane by typing this:

Why give only execute "x" permissions on the home directory? You want Dick and Jane to be able to work with the files in the trinity directory, but you'd rather keep the other things in your home directory private. Dick retries creating a file in the trinity directory, and this time he succeeds. He isn't able to see your home directory, though:

As a final test, you check the permissions on the file that he created and attempt to alter it:

You were successfully able to modify and read the file, in spite of the fact that user "dick" and group "dick" own the file. You IM Jane and ask her to give it a try:

She has the proper access, as well. All three of you can now start working concurrently on the project. And you set it up without the help of the system administrator. Sweet!

Some Caveats

Posix ACLs are certainly a major improvement in managing Linux permissions. There are some things to keep in mind, however,

ACLs are not universally supported by most of the GNU utilities that come with Linux. Commands such as mv (for moving or renaming files) will duplicate the source ACL. The copy command (cp) will too, provided that you remember to use the '-p' switch. Obviously, the target partition of one of these commands must support ACLs for them to carry over.

Perhaps the most critical application that does not support ACLs is "tar," which many installations use for backup. If you save objects secured with ACLs using the standard tar utility and then try to restore them, you'll find that your carefully crafted access control list will be missing. There are workarounds for the backup situation. Instead of the standard tar utility, use its upgraded equivalent: star. This utility works similarly to tar, but it also understands ACLs. The only problem with star is that the command line switches are different, so it may break your existing backup scripts. An alternative, and the one that I use, is to simply use the getfacl command to write the existing ACLs to a file (say ACL.list) prior to a backup. Then if I need to restore files, I can use the setfacl command along with ACL.list to restore the ACLs.

Available Now

My intent in this article was to introduce you to ACLs. While Linux has supported ACLs for quite some time, it seems that many users are totally unaware of this fact.

Properly applied, ACLs can simplify even the most complex permissions requirement. So whether you are setting up a Web server, a Samba smb server (for sharing Linux resources with Windows clients), or a system for your users to work directly on the Linux machine, you owe it to yourself to learn more. There are plenty of good Web resources that will provide much more in-depth information than I can here in this limited space. I just wanted you to be aware that ACLs support is available now. Check it out!

Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 23 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..