Access Control Lists (ACLs).
Standard permissions give you exactly three slots: owner, group, other. ACLs add as many named-user and named-group rules as you need — fine-grained access without inventing extra groups. Learn getfacl, setfacl, the mask, and the default ACLs that new files inherit.
Linux POSIX ACLs animated tutorial. getfacl, setfacl, named user and group entries, the ACL mask, default ACLs on directories, and the + indicator in ls -l. RHCSA EX200 ready.When owner / group / other runs out of slots, ACLs let you attach as many per-user and per-group rules to a file as you need.
- ·Solid on standard rwx permissions (the special-permissions lesson)
- ·Know what users and groups are
- ·Comfortable reading ls -l output
Read an ACL with getfacl, add named user/group entries with setfacl, understand the mask, and set inheritable default ACLs on directories.
pace: 9 minutes
user::rw-owner (alice)group::r--owning groupother::---everyone elseThree slots is not enough
Standard Unix permissions give you exactly three sets of rwx: the owner, ONE group, and everyone else. But what if bob needs read-only and the devs group needs full access to the SAME file, and neither is the owner? You'd have to keep inventing groups. ACLs (Access Control Lists) let you attach as many named-user and named-group rules to a file as you need.
The base permissions are ACL entries — ACLs just let you add more. Two gotchas that catch everyone: the + in ls -l means "there's an ACL here, run getfacl", and once an ACL exists, ls -l's group column shows the mask, not the owning group's real permission.
$getfacl FILE$setfacl -m u:bob:r FILE$setfacl -m g:devs:rwx FILE$setfacl -m m::r FILE$setfacl -x u:bob FILE$setfacl -b FILE$setfacl -k DIR$setfacl -d -m g:devs:rwx DIR$setfacl -R -m g:devs:rX DIR$setfacl --restore=acl.bak$getfacl -R DIR > acl.bak$cp -a / rsync -A$ls -l → trailing +$#effective: in getfacl$u:: g:: o::$mount -o acl (older fs)bob (not the owner, not in the group) needs read access to one file, and you don't want to change any group memberships. What's the cleanest fix?
You see `-rw-rwxr--+ 1 alice devs` in ls -l. What does the + mean, and what is the 'rwx' middle field actually showing?
What does the ACL mask do?
You want every new file created under /srv/project to automatically grant the devs group rwx. What do you set?
These aren't graded — they're just for active recall, which is what actually makes the lesson stick.
chmod calculator
ACLs build on standard rwx — the base entries ARE your chmod permissions. Solidify octal vs symbolic here first.
Read this lesson as text6 chapters · quiz answers
01Three slots is not enough
Standard Unix permissions give you exactly three sets of rwx: the owner, ONE group, and everyone else. But what if bob needs read-only and the devs group needs full access to the SAME file, and neither is the owner? You'd have to keep inventing groups. ACLs (Access Control Lists) let you attach as many named-user and named-group rules to a file as you need.
02getfacl — read the ACL
getfacl <file>prints the ACL. Even a file with no special ACL has three base entries that mirror the normal permissions: user:: (owner), group:: (owning group), other::. So ACLs aren't a separate system bolted on — the standard permissions ARE ACL entries. ls -l just shows them in the familiar rwxrwxrwx form.$ getfacl report.txt— show the full ACL$ ls -l report.txt— same base perms, compact form
03setfacl -m u: — grant a named user
setfacl -m u:bob:r report.txtadds a rule: bob (who isn't the owner and may not be in the group) gets read access.-mmeans modify/add. Now ls -l shows a + after the permissions to signal 'there's an ACL here'. This is the whole point: per-user access without touching group membership.$ setfacl -m u:bob:r report.txt— bob gets read$ ls -l report.txt— note the trailing +
04setfacl -m g: — grant a named group
Same idea for groups:
setfacl -m g:devs:rwx report.txtgives the devs group full access — without making devs the owning group. You can stack as many named-user and named-group entries as you like. Each is one line in getfacl output.$ setfacl -m g:devs:rwx report.txt— devs group gets rwx$ setfacl -m u:bob:r,g:qa:r f.txt— multiple entries at once
05The mask — the effective-permission ceiling
The moment you add a named entry, a mask:: entry appears. The mask is the MAXIMUM effective permission for all named users and the owning group — the rule's perms are ANDed with the mask. So even though devs has rwx, if the mask is r--, their effective permission is r--. setfacl recalculates the mask automatically; getfacl shows '#effective:' next to any entry the mask is clamping. ls -l's group field actually shows the MASK, not the owning group — a classic gotcha.
$ setfacl -m m::r report.txt— set the mask explicitly$ getfacl report.txt— see #effective: notes
06Default ACLs — inheritance on directories
On a DIRECTORY you can set a 'default' ACL with -d. It doesn't affect the directory itself — it's the template that every NEW file or subdirectory created inside inherits. Perfect for shared project folders: set a default ACL once and everything created there automatically grants the right access. Remove a single entry with -x, wipe the whole ACL with -b.
$ setfacl -d -m g:devs:rwx /srv/project— default ACL on the dir$ setfacl -x g:devs report.txt— remove one entry$ setfacl -b report.txt— strip ALL ACL entries$ setfacl -R -m g:devs:rX /srv/project— recursive (X = dir-only x)
Quiz — answers
- bob (not the owner, not in the group) needs read access to one file, and you don't want to change any group memberships. What's the cleanest fix?
- →setfacl -m u:bob:r file — a named-user ACL entry.ACLs exist precisely for this: per-user access without inventing groups or loosening permissions for everyone. A named-user entry grants bob read and leaves everyone else unchanged.
- You see
-rw-rwxr--+ 1 alice devsin ls -l. What does the + mean, and what is the 'rwx' middle field actually showing? - →+ means there's an ACL on the file; the middle (group) field actually shows the ACL MASK, not the owning group's literal permission.The + flags the presence of an ACL. Once an ACL exists, ls -l's group triad shows the mask (the effective-permission ceiling), which is why it can look different from
getfacl's group:: line. This trips people up constantly. - What does the ACL mask do?
- →Sets the MAXIMUM effective permission for named users and the owning group — each entry's perms are ANDed with the mask.The mask is a ceiling. Even if devs has rwx, a mask of r-- clamps their effective access to r--. setfacl usually recalculates it for you; getfacl marks clamped entries with #effective:.
- You want every new file created under /srv/project to automatically grant the devs group rwx. What do you set?
- →setfacl -d -m g:devs:rwx /srv/project (a DEFAULT ACL on the dir).The -d (default) ACL is the inheritance template applied to newly created files and subdirectories. A regular ACL on the directory controls access to the directory itself, not what's created inside it. (SGID on the dir handles group OWNERSHIP; default ACLs handle inherited PERMISSIONS.)
keep going — these pair well with what you just learned.
SELinux contexts
Why Apache can't read your file. Watch the policy engine decide — and learn the workflow for fixing denials. RHCSA-ready.
Linux boot process
From power button to login prompt. Every stage in the chain — UEFI, GRUB, kernel, initramfs, systemd — with the rescue moves that save you. RHCSA-ready.
LVM stacking
Layer-by-layer build of an LVM stack: disks → PVs → VG → LVs → filesystem. Then extend live and snapshot. RHCSA-ready.