Using Access Control Lists
On an ext3 filesystem, read, write, and execute permissions can be set for the owner of the file, the group associated with the file, and for everyone else who has access to the filesystem. These files are visible with the ls -l command. Refer to Chapter 4, “Understanding Linux Concepts,” for information on reading standard file permissions.
In most cases, these standard file permissions along with restricted access to mounting filesystems are all that an administrator needs to grant file privileges to users and to prevent unauthorized users from accessing important files. However, when these basic file permissions are not enough, access control lists, or ACLs, can be used on an ext3 filesystem.
ACLs expand the basic read, write, and execute permissions to more categories of users and groups. In addition to permissions for the owner and group for the file, ACLs allow for permissions to be set for any user, any user group, and the group of all users not in the group for the user. An effective rights mask, which is explained later, can also be set to restrict permissions.
To use ACLs on the filesystem, the acl package must be installed. If it is not already installed, install it via Red Hat Network as discussed in Chapter 3.
To use ACLs, they must be enabled when an ext3 filesystem is mounted. This is most commonly enabled as an option in /etc/fstab. For example:
LABEL=/share /share ext3 acl 1 2
If the filesystem can be unmounted and remounted while the system is still running, modify /etc/fstab for the filesystem, unmount it, and remount it so the changes to /etc/fstab take effect. Otherwise, the system must be rebooted to enable ACLs on the desired filesystems.
If you are mounting the filesystem via the mount command instead, use the -o acl option when mounting:
mount -t ext3 -o acl
Setting and Modifying ACLs
There are four categories of ACLs per file: for an individual user, for a user group, via the effective rights mask, and for users not in the user group associated with the file. To view the existing ACLs for a file, execute the following:
If ACLs are enabled, the output should look similar to Listing 7.10.
Listing 7.10. Viewing ACLs
# file: testfile
# owner: tfox
# group: tfox
To set or modify existing ACLs, use the following syntax:
Other useful options include --test to show the results of the command but not change the ACL and -R to apply the rules recursively.
* For an individual user:
* For a specific user group:
* For users not in the user group associated with the file:
* Via the effective rights mask:
The first three rule types (individual user, user group, or users not in the user group for the file) are pretty self-explanatory. They allow you to give read, write, or execute permissions to users in these three categories. A user or group ID may be used, or the actual username or group name.
If the actual username or group name is used to set an ACL, the UID or GID for it are still used to store the ACL. If the UID or GID for a user or group name changes, the ACLs are not changed to reflect the new UID or GID.
But, what is the effective rights mask? The effective rights mask restricts the ACL permission set allowed for users or groups other than the owner of the file. The standard file permissions are not affected by the mask, just the permissions granted by using ACLs. In other words, if the permission (read, write, or execute) is not in the effective rights mask, it appears in the ACLs retrieved with the getfacl command, but the permission is ignored. Listing 7.11 shows an example of this where the effective rights mask is set to read-only, meaning the read-write permissions for user brent and the group associated with the file are effectively read-only. Notice the comment to the right of the ACLs affected by the effective rights mask.
Listing 7.11. Effective Rights Mask
# file: testfile
# owner: tammy
# group: tammy
The effective rights mask must be set after the ACL rule types. When an ACL for an individual user (other than the owner of the file) or a user group is added, the effective rights mask is automatically recalculated as the union of all the permissions for all users other than the owner and all groups including the group associated with the file. So, to make sure the effective rights mask is not modified after setting it, set it after all other ACL permissions.
If the ACL for one of these rule types already exists for the file or directory, the existing ACL for the rule type is replaced, not added to. For example, if user 605 already has read and execute permissions to the file, after the u:605:w rule is implemented, user 605 only has write permissions.
Setting Default ACLs
Two types of ACLs can be used: access ACLs, and default ACLs. So far, this chapter has only discussed access ACLs. Access ACLs are set for individual files and directories. Directories, and directories only, can also have default ACLs, which are optional. If a directory has a default ACL set for it, any file or directory created in the directory with default ACLs will inherit the default ACLs. If a file is created, the access ACLs are set to what the default ACLs are for the parent directory. If a directory is created, the access ACLs are set to what the default ACLs are for the parent directory and the default ACLs for the new directory are set to the same default ACLs as the parent directory.
To set the ACL as a default ACL, prepend d: to the rule such as d:g:500:rwx to set a default ACL of read, write, and execute for user group 500. If any default ACL exists for the directory, the default ACLs must include a user, group, and other ACL at a minimum as shown in Listing 7.12.
Listing 7.12. Default ACLs
# file: testdir
# owner: tfox
# group: tfox
If a default ACL is set for an individual user other than the file owner or for a user group other than the group associated with the file, a default effective rights mask must also exist. If one is not implicitly set, it is automatically calculated as with access ACLs. The same rules apply for the default ACL effective rights mask: It is recalculated after an ACL for any user other than the owner is set or if an ACL for any group including the group associated with the file is set, meaning it should be set last to ensure it is not changed after being set.
The setfacl -x
It is also possible to remove all ACLs for a file or directory with:
To remove all default ACLs for a directory:
The NFS and Samba file sharing clients in Red Hat Enterprise Linux recognize and use any ACLs associated with the files shared on the server. If your NFS or Samba clients are not running Red Hat Enterprise Linux, be sure to ask the operating system vendor about ACL support or test your client configuration for support.
The mv command to move files preserves the ACLs associated with the file. If it can’t for some reason, a warning is displayed. However, the cp command to copy files does not preserve ACLs.
The tar and dump commands also do not preserve the ACLs associated with files or directories and should not be used to back up or archive files with ACLs. To back up or archive files while preserving ACLs use the star utility. For example, if you are moving a large number of files with ACLs, create an archive of all the files using star, copy the star archive file to the new system or directory, and unarchive the files. Be sure to use getfacl to verify that the ACLs are still associated with the files. The star RPM package must be installed to use the utility. Refer to Chapter 3 for details on package installation via Red Hat Network. The star command is similar to tar. Refer to its man page with the man star command for details.