Standard Linux file permissions describe only the owner, the owning group and everyone else. What do POSIX ACLs add on top of that model, and how can you tell from `ls -l` output that a file carries one?
answer
- more than owner, group, other
- named users and groups
- one extra letter in ls -l
- getfacl to see the full list
basics
~20 sPOSIX ACLs extend Unix permissions with entries for individually named users and groups, so one person can be granted rights on a file without changing its owner or the group everyone belongs to. In ls -l, a trailing plus sign after the mode marks such a file.
solid answer
~40 sThe classic mode bits can only express three principals: the owning user, the owning group, and everyone else. POSIX ACLs add extra entries to the same inode, so you can say "bob may write this file" without making bob the owner or adding him to a group that grants him access everywhere else that group is used. You read them with `getfacl` and set them with `setfacl`, for example `setfacl -m u:bob:rw report.txt`. The entry types are `user::` (owner), `user:NAME:`, `group::` (owning group), `group:NAME:`, `mask::` and `other::`. A file with only the three base entries has a *minimal* ACL, exactly equivalent to its mode bits; once named entries exist it is an *extended* ACL, and `ls -l` appends a `+` to the mode string as the visible signal.
go deeper
Know that ACLs let you grant a specific named user or group rights on a file, that getfacl prints them and setfacl -m sets them, and that a trailing + in ls -l is the visible clue.
Be able to name the entry types, explain that a minimal ACL is just the mode bits while an extended ACL adds named entries plus a mask, and describe how the kernel picks one matching class rather than combining several.
Show that you check for the + when permissions behave unexpectedly, and that you know the entries live in extended attributes, so filesystem support and copy tooling decide whether they survive.
Frame ACLs as per-path exception state that no central directory service knows about, and be ready to say where you allow them versus where you require the access to be expressed as group membership.
## Why the classic model runs out Every Linux inode stores an owner UID, an owning group GID, and nine permission bits arranged as three triads: read/write/execute for the owner, for the owning group, and for everyone else. That is the whole vocabulary — three principals, no more. It is compact and fast, and for most files it is enough. It breaks the moment you need a *fourth* opinion. Say `/srv/reports/q3.csv` is owned by `alice:analysts` and you must let the single user `bob` write it. Your options without ACLs are all bad: - Change the owner to bob — now alice loses her ownership rights. - Add bob to `analysts` — that grants him everything the analysts group can reach anywhere on the system, not just this one file. - Create a brand-new group for the pair and `chgrp` the file — needs privileged group administration, and repeating it per exception produces hundreds of single-purpose groups. POSIX ACLs (the `POSIX 1003.1e draft 17` model that Linux implements) exist for exactly this case: an *access control list* of arbitrarily many entries attached to the file, each naming a principal and the rights it gets. ## What an ACL is made of An ACL is an ordered set of entries, each of the form `type:qualifier:permissions`: | Entry | Meaning | |---|---| | `user::rw-` | the file's owner (no qualifier) | | `user:bob:rw-` | a **named user** entry | | `group::r--` | the file's owning group | | `group:devs:r-x` | a **named group** entry | | `mask::rwx` | upper bound on all named entries and the owning group | | `other::r--` | everyone else | An ACL containing only `user::`, `group::` and `other::` is called a **minimal ACL** — it holds exactly the information the nine mode bits already hold, and the kernel keeps it in the inode's mode field rather than as a separate object. Add any named entry and it becomes an **extended ACL**: a `mask::` entry appears automatically, and the list is stored as an extended attribute. Access is decided by matching the process against the most specific entry: owner first, then a matching named-user entry, then the owning group and named group entries, and finally `other`. Only one class is consulted — being denied by your matching named-user entry does *not* fall through to a more generous group entry. ## Reading and writing them ``` $ setfacl -m u:bob:rw report.txt $ getfacl report.txt # file: report.txt # owner: alice # group: analysts user::rw- user:bob:rw- group::r-- mask::rw- other::r-- ``` `setfacl -m` modifies or adds entries; `setfacl -x u:bob report.txt` removes one (no permission field when removing); `setfacl -b report.txt` strips every extended entry and returns the file to a minimal ACL. ## The `+` marker Because `ls -l` still prints only nine characters, an ACL would otherwise be invisible. GNU `ls` therefore appends a `+` after the mode string when a file has an alternate access method such as an extended ACL: ``` -rw-rw-r--+ 1 alice analysts 812 Aug 20 11:04 report.txt ``` That plus sign is the only hint in ordinary directory listings, and it is the habit worth building: when permissions on a file behave in a way the visible bits do not explain, look for the `+` and run `getfacl`. Note also that once the ACL is extended, the *middle* triad in `ls -l` is showing the `mask` entry, not the owning group's own entry — a detail that surprises people reading listings on ACL-managed trees. ## Where they are stored, and where they work ACLs are not a separate database; they are stored per file as extended attributes on the filesystem, so a filesystem that cannot hold extended attributes cannot hold ACLs. `ext4`, `xfs` and `btrfs` all support them and enable them by default on current kernels; `vfat` and `exfat` cannot store them at all. This is also why ACLs are easy to lose in a copy or a restore — the mode bits travel almost everywhere, the extra entries only travel with tools that deliberately carry them. ## When to reach for them ACLs are the right tool for genuine per-path exceptions: a service account that must write into one directory, a drop-box a partner team appends to, an auditor granted read on one tree. They are the wrong tool for expressing an organisation's role structure — that is what groups are for, because group membership is managed centrally and visible without walking the filesystem.
- What is the difference between a minimal and an extended ACL?A minimal ACL has only the three base entries — `user::`, `group::` and `other::` — and is exactly equivalent to the file's nine mode bits, so no extra storage is needed. An extended ACL adds named user or group entries plus a `mask` entry; it is stored as an extended attribute and is what makes `ls -l` print the trailing `+`.
- How do you remove every ACL entry from a file and return it to plain mode bits?`setfacl -b file` removes all extended entries, leaving a minimal ACL equivalent to the mode bits, and the `+` disappears from `ls -l`. On a directory, `setfacl -k dir` removes only the default (inheritance) ACL while leaving the access ACL alone. Check the result with `getfacl` rather than trusting the listing.
- If a user matches both a named-user entry and a group entry, which one wins?The named-user entry decides, and the group entries are not consulted at all. The kernel picks the most specific matching class — owner, then named user, then the group class, then other — and evaluates only that one. So a `user:bob:r--` entry denies bob write access even if a group he belongs to has `rw-`.
saying these in an interview costs you the question
- Thinking ACLs replace the mode bits rather than extending them
- Assuming ls -l shows ACL entries if you look closely
- Claiming any user can grant themselves an ACL entry
- Believing ACLs work identically on every filesystem
- Confusing POSIX ACLs with SELinux labels or NTFS ACLs