Access Control List Concepts
Standard Linux file permissions are satisfactory when files are used by only a single owner, and a single designated group of people. However, some use cases require that files are accessed with different file permission sets by multiple named users and groups. Access Control Lists (ACLs) provide this function.
With ACLs, you can grant permissions to multiple users and groups, identified by user name, group name, UID, or GID, using the same permission flags used with regular file permissions: read, write, and execute. These additional users and groups, beyond the file owner and the file's group affiliation, are called named users and named groups respectively, because they are named not in a long listing, but rather within an ACL.
Users can set ACLs on files and directories that they own. Privileged users, assigned the CAP_FOWNER Linux capability, can set ACLs on any file or directory. New files and subdirectories automatically inherit ACL settings from the parent directory's default ACL, if they are set. Similar to normal file access rules, the parent directory hierarchy needs at least the other search (execute) permission set to enable named users and named groups to have access.
File-system ACL Support
File systems need to be mounted with ACL support enabled. XFS file systems have built-in ACL support. Other file systems, such as ext3 or ext4 created on Red Hat Enterprise Linux 8, have the acl option enabled by default, although on earlier versions you should confirm that ACL support is enabled. To enable file-system ACL support, use the ACL option with the mount command or in the file system's entry in /etc/fstab configuration file.
Viewing and Interpreting ACL Permissions
The ls -l command only outputs minimal ACL setting details:
The plus sign (+) at the end of the 10-character permission string indicates that an extended ACL structure with entries exists on this file.
user:
Shows the user ACL settings, which are the same as the standard user file settings; rwx.
group:
Shows the current ACL mask settings, not the group owner settings; rw.
other:
Shows the other ACL settings, which are the same as the standard other file settings; no access.
View File ACLs
To display ACL settings on a file, use getfacl file:
Review each section of the previous example:
Commented entries:
The first three lines are comments that identify the file name, owner (user), and group owner (operators). If there are any additional file flags, such as setuid or setgid, then a fourth comment line will appear showing which flags are set.
User entries:
1.File owner permissions. user has rwx.
2.Named user permissions. One entry for each named user associated with this file. consultant3 has no permissions.
3.Named user permissions. UID 1005 has rwx, but the mask limits the effective permissions to rw only
Group entries:
1.Group owner permissions. operators has rwx, but the mask limits the effective permissions to rw only.
2.Named group permissions. One entry for each named group associated with this file. consultant1 has r only.
3.Named group permissions. GID 2210 has rwx, but the mask limits the effective permissions to rw only.
Mask entry:
Mask settings show the maximum permissions possible for all named users, the group owner, and named groups. UID 1005, operators, and GID 2210 cannot execute this file, even though each entry has the execute permission set.
Other entry:
Other or "world" permissions. All other UIDs and GIDs have NO permissions.
Viewing Directory ACLs
To display ACL settings on a directory, use the getfacl directory command:
Review each section of the previous example:
Opening comment entries:
The first three lines are comments that identify the directory name, owner (user), and group owner (operators). If there are any additional directory flags (setuid, setgid, sticky), then a fourth comment line shows which flags are set; in this case, setgid.
Standard ACL entries:
The ACL permissions on this directory are the same as the file example shown earlier, but apply to the directory. The key difference is the inclusion of the execute permission on these entries (when appropriate) to allow directory search permission.
Default user entries:
1.Default file owner ACL permissions. The file owner will get rwx, read/write on new files and execute on new subdirectories.
2.Default named user ACL permissions. One entry for each named user who will automatically get the default ACL applied to new files or subdirectories. consultant3 always defaults to no permissions.
Default group entries:
1.Default group owner ACL permissions. The file group owner will get rwx, read/write on new files and execute on new subdirectories.
2.Default named group ACL permissions. One entry for each named group which will automatically get the default ACL. consultant1 will get rx, read-only on new files, and execute on new subdirectories.
Default ACL mask entry:
Default mask settings show the initial maximum permissions possible for all new files or directories created that have named user ACLs, the group owner ACL, or named group ACLs: read and write for new files and execute permission on new subdirectories. New files never get execute permission.
Default other entry:
Default other or "world" permissions. All other UIDs and GIDs have no permissions to new files or new subdirectories.
The default entries in the previous example do not include the named user (UID 1005) and named group (GID 2210); consequently, they will not automatically get initial ACL entries added for them to any new files or new subdirectories. This effectively limits them to files and subdirectories that they already have ACLs on, or if the relevant file owner adds the ACL later using setfacl. They can still create their own files and subdirectories.
The ACL Mask
The ACL mask defines the maximum permissions that you can grant to named users, the group owner, and named groups. It does not restrict the permissions of the file owner or other users. All files and directories that implement ACLs will have an ACL mask.
The mask can be viewed with getfacl and explicitly set with setfacl. It will be calculated and added automatically if it is not explicitly set, but it could also be inherited from a parent directory default mask setting. By default, the mask is recalculated whenever any of the affected ACLs are added, modified, or deleted.
*ACL Permission Precedence
*
When determining whether a process (a running program) can access a file, file permissions and ACLs are applied as follows:
- If the process is running as the user that owns the file, then the file's user ACL permissions apply.
- If the process is running as a user that is listed in a named user ACL entry, then the named user ACL permissions apply (as long as it is permitted by the mask).
- If the process is running as a group that matches the group owner of the file, or as a group with an explicitly named group ACL entry, then the matching ACL permissions apply (as long as it is permitted by the mask).
- Otherwise, the file's other ACL permissions apply.
Examples of ACL Use by the Operating System
Red Hat Enterprise Linux has examples that demonstrate typical ACL use for extended permission requirements.
ACLs on Systemd Journal Files
systemd-journald uses ACL entries to allow read access to the /run/log/journal/cb44...8ae2/system.journal file to the adm and wheel groups. This ACL allows the members of the adm and wheel groups to have read access to the logs managed by journalctl without having the need to give special permissions to the privileged content inside /var/log/, like messages, secure or audit.
Due to the systemd-journald configuration, the parent folder of the system.journal file can change, but the systemd-journald applies ACLs to the new folder and file automatically.
ACL on Systemd Managed Devices
systemd-udev uses a set of udev rules that enable the uaccess tag to some devices, such as CD/DVD players or writers, USB storage devices, sound cards, and many others. The previous mentioned udev rules sets ACLs on those devices to allow users logged in to a graphical user interface (for example gdm) to have full control of those devices.
The ACLs will remain active until the user logs out of the GUI. The next user who logs in to the GUI will have a new ACL applied for the required devices.
In the following example, you can see the user has an ACL entry with rw permissions applied to the /dev/sr0 device that is a CD/DVD drive.
Top comments (0)