File permissions and ACLs — when chmod isn't enough

The chmod/chown trio (owner-group-other × read-write-execute) is enough for most file permission needs. When it isn't — when you need a fourth identity, or per-user grants beyond the group model — POSIX ACLs are the next step up. This article covers both, and when to pick one over the other.

The basics recap

chown alice:dev /opt/myapp          # owner alice, group dev
chmod 0640 /opt/myapp/secret.yaml   # rw owner, r group, --- other
chmod g+s /opt/myapp                # SETGID directory — new files inherit the group

The SETGID-on-directory trick is the most commonly-missed standard-permissions tool — combine with chmod 2775 /shared and any file created in /shared by anyone gets group ownership of /shared's group, solving most "two users want to collaborate on the same files" cases without ACLs.

The "umask" piece

New files inherit permissions based on the creating process's umask. Default 0022 means new files are 0644, new dirs are 0755. To make a process create files restricted to its own user only:

# In a systemd unit
[Service]
UMask=0077                    # files 0600, dirs 0700

For shells, set in ~/.bashrc or system-wide in /etc/profile:

umask 0027                     # files 0640, dirs 0750

When you need ACLs

Standard permissions support one user (owner), one group, and "other." ACLs give you per-user and per-group grants on top of that, useful when:

• Two unrelated groups need different access levels to the same files (group A read-only, group B read-write).
• One specific user needs access to files owned by an unrelated user/group.
• You want default-permissions on a directory applied to newly-created children regardless of who created them.

Enabling ACLs

Most modern filesystems (ext4, xfs, btrfs) support ACLs natively. To use them:

apt install acl                            # Debian/Ubuntu
dnf install acl                            # AlmaLinux

# Check current ACLs (always works, even if no ACL is set — shows standard perms)
getfacl /opt/myapp/secret.yaml

Setting ACLs

# Grant user bob read-write on a file alice owns
setfacl -m u:bob:rw /opt/myapp/secret.yaml

# Grant group ops read on a directory tree, recursively
setfacl -R -m g:ops:r /var/log/myapp

# Set DEFAULT ACL — new files in this dir inherit these grants
setfacl -d -m u:bob:rw /opt/myapp
setfacl -d -m g:ops:r /opt/myapp

# Remove an ACL entry
setfacl -x u:bob /opt/myapp/secret.yaml

# Strip all ACLs from a file (back to standard perms)
setfacl -b /opt/myapp/secret.yaml

When a file has ACLs, ls -l shows a trailing +:

$ ls -l secret.yaml
-rw-r-----+ 1 alice dev 412 Jun 22 14:30 secret.yaml
              ^                              

Use getfacl to see the full picture:

$ getfacl secret.yaml
# file: secret.yaml
# owner: alice
# group: dev
user::rw-
user:bob:rw-
group::r--
mask::rw-
other::---

The "mask" thing

ACLs introduce a mask — the maximum permissions any ACL grant can actually convey. When you chmod g+rw a file with ACLs, you're modifying the mask, not the group ACL entry directly. This trips people up: granting u:bob:rw and then chmod g-w the file silently revokes bob's write access because the mask is now r-only.

To keep this straight, prefer chmod and setfacl on the same file rarely; once you go ACL, manage permissions via setfacl and use chmod only for the owner/owner-group permissions.

Backup tools and ACLs

Most file-level backup tools preserve ACLs if you ask:

• rsync: -A (acls) and -X (xattrs) flags. Together with -a covers permissions + ACLs + extended attributes.
• tar: --acls --xattrs on GNU tar.
• cp: --preserve=all.
• restic, borg: preserve ACLs by default on Linux.

If you migrate data between filesystems and lose ACLs, the symptom is "permissions look right but everything broke" — silent loss of per-user grants. Worth running getfacl -R /source > /tmp/acls.txt before the move and setfacl --restore=/tmp/acls.txt after, as a sanity check.

SELinux contexts (AlmaLinux)

On AlmaLinux with SELinux enforcing, file contexts are a separate identity layer on top of permissions/ACLs. A file that's chmod'd correctly can still be inaccessible to a service if its SELinux context is wrong. See the dedicated SELinux article in this category for the common patterns; the relevant tools are ls -Z, chcon, restorecon, semanage fcontext.

When NOT to use ACLs

• When standard perms + a thoughtful group structure would suffice — ACLs add complexity that another sysadmin has to read later. Use them when the access model genuinely needs them.
• On filesystems mounted from a network share where the server doesn't support ACLs — silently dropped.
• When you'll be syncing to another filesystem type — make sure ACL preservation is in your tooling chain.