Linux File Security Training at the ACLU

If user and group management has you in a quandary, it's time to take the advanced filesystem security class at the ACLU.

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:

$ getfacl

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.

Back Story

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.

$ ls -l file.txt

-rw-r--r-- 1 root root 6 Apr 23 17:38 file.txt

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.

$ ls -l file2.txt

-rw-rw-r--+ 1 root root 6 Apr 23 17:38 file2.txt

GETFACL

The /usr/bin/getfacl (get file access control lists) program displays minimal ACLs and extended ACLs. As a comparative example, look at the two files simultaneously.

$ getfacl *

# file: file1.txt
# owner: root
# group: root
user::rw-
group::r--
other::r--

# file: file2.txt
# owner: root
# group: root
user::rw-
user:khess:rw-
group::r--
mask::rw-
other::r--

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--
other            r--

# file: file2.txt
USER   root      rw-
user   khess     rw-
GROUP  root      r--
mask             rw-
other            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-.

SETFACL

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.

$ sudo setfacl -m user:khess:rw file2.txt

$ getfacl file2.txt

# file: file2.txt
# owner: root
# group: root
user::rw-
user:khess:rw-
group::r--
mask::rw-
other::r--

Add another user, robert, to the ACL for file2.txt.

$ sudo setfacl -m user:robert:rw file2.txt

$ getfacl file2.txt

# file: file2.txt
# owner: root
# group: root
user::rw-
user:khess:rw-
user:robert:rw-
group::r--
mask::rw-
other::r--

After some consideration, it’s decided that user robert doesn’t need write access to file2.txt. Instead of removing his access and then reinstating it, you can modify (-m) his access.

$ sudo setfacl -m user:robert:r file2.txt

$ getfacl file2.txt

getfacl file2.txt
# file: file2.txt
# owner: root
# group: root
user::rw-
user:khess:rw-
user:robert:r-
group::r--
mask::rw--
other::r--

After much more consideration, it’s found that user robert needs no rights to the file.

$ sudo setfacl -x user:robert file2.txt

$ getfacl file2.txt

getfacl file2.txt
# file: file2.txt
# owner: root
# group: root
user::rw-
user:khess:rw-
group::r--
mask::rw-
other::r--

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.

$ sudo chmod 666 file2.txt

$ rm file2.txt

rm: cannot remove 'file2.txt': Permission denied

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.

$ sudo setfacl -m user:khess:rwx Filedir

$ getfacl Filedir

# file: Filedir
# owner: root
# group: root
user::rwx
user:khess:rwx
group::r-x
mask::rwx
other::r-x

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.

CHACL

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.

$ sudo chacl -B file2.txt 

$ getfacl file2.txt

# file: file2.txt
# owner: root
# group: root
user::rw-
group::r--
other::r--

Next week, you’ll dive deeper into ACLs now that the introductory material out of the way.

Is there a topic you’d like covered in the System Administration column? If there is, send me an email and I’ll put your request into the queue.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62