Most linux admins stop at basic file permissions and ignore using and learning Access Control Lists. ACL's is a very powerfull extenstion to basic file permissions. For example with ACLs you can set up a file in your home directory that can be read by a limited number of other users and groups. At the very least every linux admin should know how to create and manage access control lists.
With ACLs we can give selected users read, write and execute permissions to selected files in your home directory. This provides a second level of discretionary access control, a way that supports overriding the standard ugo/rwx permissions.
The two commands you need to get familiar with are:
A basic example use of getfacl is shown as follows:
[root@localhost]# getfacl /root getfacl: Removing leading '/' from absolute path names # file: root # owner: root # group: root user::r-x group::r-x other::---
The above command was executed to get the attributes for /root. There are no ACL's. Access to /root is defined only by the standard ugo permissions.
RHEL 7 by default uses XFS which have ACLs by default. Also creating ext2/ext3/ext4 filesystems in RHEL7 has ACLs by default. We can find out if our partition has ACLs enabled as follows:
[root@localhost~]# tune2fs -l /dev/mapper/fedora-root | grep acl Default mount options: user_xattr acl
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.
# file: testfile # owner: tfox # group: tfox user::rwx group::r-x mask::rwx other::r-x
To set or modify existing ACLs, use the following syntax:
setfacl -m <rules> <file>
Other useful options include --test to show the results of the command but not change the ACL and -R to apply the rules recursively.
Replace <file> with one or more space-separated file or directory names. Rules can be set for four different rule types. Replace <rules> with one or more of the following, and replace <perms> in these rules with one or more of r, w, and x (which stand for read, write, and execute):
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
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 user::rwx group::r-x mask::rwx other::r-x default:user::rwx default:group::r-x default:other::r--
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 <rules> <file> command can be used to remove ACL permissions by ACL rule type. The <rules> for this command use the same syntax as the setfacl -m <rules> <file> command except that the <perms> field is omitted because all rules for the rule type are removed.
It is also possible to remove all ACLs for a file or directory with:
setfacl --remove-all <file>
To remove all default ACLs for a directory:
setfacl --remove-default <dir>
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.