File Access Controls and ACLs

Linux file permissions are the security system that decides what each user can do with a file or directory. Every file and directory has three sets of permissions, one for the file's owner, one for the group that owns the file, and one for everyone else. These three sets control read (r), write (w), and execute (x) access. This standard model works well when you only need to manage a few users, but in real organisations you often need to give a specific user outside the owning group some extra access, or let multiple groups have different levels of access to the same file.

Access Control Lists, or ACLs, solve this problem by attaching a detailed list of permissions to a file or directory. Instead of just three slots (owner, group, others), ACLs allow you to add entries for any specific user or any specific group. For example, you can give user \"alice\" read and write permissions on a file that her team owns, while user \"bob\" from a different department gets only read permission, all without changing the underlying owner or group. The basic permissions still exist and act as the default, but ACL entries add extra rules.

The two main types of ACLs are access ACLs and default ACLs. Access ACLs control permissions on a specific file or directory. Default ACLs only apply to directories, and they set the starting permissions that any new file or subdirectory created inside that directory will inherit. When you set a default ACL on a directory, every new item created inside it automatically gets those same ACL entries. This is extremely useful for shared project folders where every team member needs consistent access to new files.

To view ACLs, you use the \"getfacl\" command. This command shows you the current ACL entries for a file or directory, including the three standard owner/group/others entries, plus any additional user or group entries. The output shows the exact permissions each entry allows. To set or modify ACLs, you use the \"setfacl\" command. The most common options are:

When you use setfacl, you specify the type of entry you are adding. For example, \"setfacl -m u:alice:rw file.txt\" gives user alice read and write permissions on file.txt. The pattern is always the letter \"u\" for user, a colon, the username, another colon, and then the permissions in symbolic form (r, w, x). For groups, you use \"g\" instead of \"u\", as in \"setfacl -m g:developers:rx project\". For others (everyone not covered by other entries), you use \"o\".

ACLs introduce the concept of a mask. The mask is a limit that restricts the maximum permissions that any named user or named group can get through ACLs, though it does not affect the file's owner or the others entry. When you set an ACL on a file, the mask is automatically recalculated to be the union of all permissions granted to named users and named groups. You can also set the mask explicitly with \"setfacl -m m::rwx file.txt\". The mask is crucial because it can silently reduce the effective permissions of ACL entries. If the mask only allows read, then even if an ACL entry grants write permission, that write permission will be blocked. Beginners often forget this and cannot understand why an ACL entry seems to be ignored.

Default ACLs work differently. When you set a default ACL on a directory, it does not change the permissions of existing files inside that directory. Instead, it only affects new files and subdirectories created in the future. For example, if you set a default ACL that gives the group \"accounting\" read access, any new file created in that directory will automatically give that group read access. The command to set a default ACL uses the -d flag, like \"setfacl -d -m g:accounting:rx sharedir\".

ACLs replace the need to create many special groups just to manage permissions. Without ACLs, if you wanted to give user \"charlie\" access to a file owned by the \"engineering\" group, you would either have to change the file's group or add charlie to the engineering group, both of which have side effects. ACLs let you grant that access directly without modifying group memberships or ownership. The entire system is managed through extended attributes on the filesystem, which means the filesystem must support ACLs. On Red Hat Enterprise Linux, the default filesystem (XFS) fully supports ACLs out of the box, so you do not need to enable anything.

Imagine you work as a junior system administrator for a medium-sized company that develops software. The company has a shared server where the development team stores project files in a directory called /opt/projects. The directory is owned by the user \"devlead\" and the group \"developers\". The basic permissions are rwx for the owner, rwx for the group, and --- for others, meaning only the devlead user and members of the developers group can access it.

One day, the finance department needs to audit some configuration files stored in a subdirectory called /opt/projects/config. The auditor, whose username is \"auditor\", is not a member of the developers group. You cannot add the auditor to the developers group because that would give them access to all development files, which is a security risk. You also cannot change the owner or group of the config files because that would break automated scripts.

This is where ACLs save the day. You navigate to the /opt/projects directory and run the command \"setfacl -m u:auditor:rx config\". This gives the auditor user read and execute permissions on the config directory and its contents, but does not give them any access to other parts of /opt/projects. The finance department can complete their audit without any security breach.

Later, the development team creates a new shared workspace for a joint project with the quality assurance team. They want every new file created in this workspace to automatically be readable by the QA team. Instead of asking you to modify permissions on each new file, you set a default ACL on the workspace directory:

Now, every time a developer creates a new file in the workspace directory, the file automatically gets an ACL entry granting read and execute access to the QA group. The developers do not need to remember to change permissions manually. If the QA team later leaves the project, you can remove the ACL entry with \"setfacl -x g:qateam /opt/projects/workspace\" and also \"setfacl -x g:qateam /opt/projects/workspace\" for the default ACL, using the -d flag.

In a real production environment, you might also encounter situations where a script fails because the mask is too restrictive. For example, you grant a user write permission with setfacl, but when they try to edit the file, they get a permission denied error. Checking the mask with \"getfacl\" reveals that the mask entry shows only r-x, even though the user's ACL entry shows rw-. The fix is to explicitly set the mask with \"setfacl -m m::rwx file\" or just reapply the ACL entries, which recalculates the mask automatically. These real-world troubleshooting steps are exactly what the EX200 exam tests.