A couple of weeks ago you learned some user and group management basics with “User and Group Management 101.” This week you’re entering the Access Control List University (ACLU) for an overview of advanced user and group management through the use of access control lists (ACLs).
ACLs don’t negate standard user and group management; they enhance it by expanding and simplifying complex permissions needs. User and group management, including ACLs, can fill an entire book so this introduction attempts to whet your appetite for a more in-depth investigation and isn’t meant to provide a treatise on the topic.
Before starting the tutorial, make sure that you have the acl package installed on your system. Check by issuing the getfacl command at a prompt. You should see a message similar to the following:
Try `getfacl --help' for more information.
You likely have acl installed, if you receive a response other than, “command not found.” If you find that acl isn’t installed on your system, install it via your system’s package manager.
The permissions that you’re familiar with are of the u, g, o and rwx types. You view these permissions with ls -l and change them with the chmod command. In ACL terminology, these are known as the “minimal” access control list. Entries beyond this minimal list are known as the extended access control list. The Extended ACL shows permissions not shown in standard ls -l file listings. The file below only shows the typical ugo and rwx type permissions.
Through standard commands, you only see the minimal ACL. And, for most files, this is enough information. Even the most restricted files only show minimal ACLs because they only have minimal ACLs. Examples, as shown in upcoming sections, are /etc/passwd and /etc/shadow.
It’s a subtle change but for files with extended ACLs, you’ll notice a “+” in the 11th bit position. You can see this with the long list command.
As you can see, user khess has read and write permission as a user owner for file2.txt. The root user and user khess have full control of file2.txt.
For some administrators, the default getfacl view isn’t particularly easy to read. There is a tabular view that gives you a clearer presentation of extended ACLs.
$ getfacl --tabular *
# file: file1.txt
USER root rw-
GROUP root r--
# file: file2.txt
USER root rw-
user khess rw-
GROUP root r--
Not only does this view present the extended permissions in a tabular format, it also makes a distinction between original owner (ALL CAPS) and extended ownership (lower case). From the example above, the root user is the original owner, shown as: USER root rw-. And, khess is the extended owner: user khess rw-.
Files aren’t created with extended permissions or ACLs; they’re added later. It is the setfacl program that sets those extended permissions for you. The syntax for setfacl is a little tricky but once you see its madness in action, you’ll catch on to its method.
For each of the setfacl examples, you’ll have the setfacl command presented to you and then the getfacl results of that command. You can set ACL permissions by using the setfacl in the following ways:
Modify (-m) the ACL for file2.txt, setting user khess with read and write access.
Here’s a question for you about what you’re seeing in the example above. This file is owned by the root user, however, user khess has read and write access to it through ACLs. Can user khess edit file2.txt? Can the user khess remove the file?
$ echo "I can write to the file" > file2.txt
$ cat file2.txt
I can write to the file
$ rm file2.txt
rm: cannot remove 'file2.txt': Permission denied
User khess can open the file, write to it and save it but not remove the file. Do you know why? If you think it’s file permissions related, then try granting write access to everyone for file2.txt.
Only the root user has the right to remove the file. Why? Hint: It’s the permissions on the directory in which the file is located. Setting ACLs on directories is the same as setting ACLs on any other file. Remember that directories are files too. Now that you know that user khess can’t remove the files, try the following experiment.
Now user khess can remove any file within the Filedir directory regardless of ownership.
As an interesting experiment in ACLs, set the permissions on Filedir for user khess as rw. What happens? User khess can’t cd into Filedir even if other has read and execute permissions. The execute permission (x) allows a user to cd into a directory. Extended ACLs take precendence over minimal ACLs. All other users can cd into Filedir.
The chacl command is included for IRIX compatibility. The preferred way to change ACLs is to use the setfacl command. It’s assumed that chacl will be deprecated at some point in the future in favor of setfacl. Although, setfacl is preferred, the chacl command offers some compelling shortcuts that are less frustrating than their setfacl counterparts. For example, removing all extended ACLs, which resets access to the original minimal ACL.