Developer tools · Chmod calculator
POSIX ACLs vs chmod mode bits: when rwx is not enough
· Background
chmod unix access-control
Mode bits cover one owner, one group and everyone else. This post explains the POSIX.1e ACL model that fills the gap, how it interacts with chmod, and when a shared group is still the simpler answer.
One more reader than the model allows — a file belongs to the app group, and one auditor outside the group needs to read it
The ordinary mode model has no fourth identity slot. It can describe permissions for one owner, one group, and everyone else, but it cannot name an additional auditor. The calculator mirrors that boundary exactly: its matrix, symbolic display, and summaries expose those three classes plus special bits, not per-user or per-group access entries.
Widening the other class merely to accommodate one extra reader would affect every identity falling into that class. The calculator can show that arithmetic change, such as moving from 0640 to 0644, but it cannot decide whether broader access is acceptable. Named access requires evidence and tooling outside this route.
The limit of three classes — why the traditional model has exactly one slot each for owner, group and others
Each trailing octal digit belongs to one fixed class. Owner, group, and other receive read, write, and execute flags, producing nine ordinary positions. The model cannot insert another triple for a named person. A successful conversion therefore describes the base mode faithfully while saying nothing about additional entries attached elsewhere.
This limitation matters when reading apparently restrictive output. A symbolic value of rw-r----- tells you the base owner, group, and other bits represented by 0640. It does not prove that no other identity can read the object, because the calculator neither inspects ACL data nor observes any external enforcement layer.
POSIX.1e ACLs — named user and named group entries added to the same file, set with setfacl and read with getfacl
Named user and named group entries are not implemented. The source contains no parser or formatter for ACL records, no ACL mask, and no setfacl or getfacl operation. Those concepts may motivate using an external access-control mechanism, but this article cannot specify command syntax or behavior beyond acknowledging the calculator's explicit boundary.
Keep the base mode visible while performing that separate work. Enter the reported octal value, verify the owner, group, and other triples, and record any special bit. Then use authoritative filesystem documentation and suitable external tools for named entries. The calculator's generated chmod preview does not create, inspect, or preserve an ACL.
Named ACL entries require external tools not implemented here
The relationship between a chmod change, group-class bits, and an ACL mask depends on behavior not implemented here. The calculator simply converts a twelve-bit mode and emits an assignment or octal argument. It has no ACL state against which to calculate effective rights, so it cannot forecast whether a named entry would be capped.
Avoid describing an ACL consequence from mode output alone. A change from 0640 to 0600 demonstrably removes the three group-class bits in this model; anything about named users, named groups, or masks requires the actual ACL and platform rules. Verify those with filesystem documentation before applying the displayed command to an ACL-bearing object.
ACL mask interaction with chmod needs filesystem documentation
Default ACL inheritance is also beyond the route. The page has no directory ACL input, no creation operation, and no umask field. Switching the target selector from file to directory changes the plain-English verbs attached to a fixed mode; it does not create a file, model inheritance, or calculate a future object's permissions.
For the same reason, a current directory mode cannot predict every new child's mode here. The calculator can explain that directory read, write, and execute correspond to listing, modifying entries, and reaching named contents. It cannot combine those base bits with default entries, creation requests, or process masks that it never receives.
Default ACL inheritance and umask interaction are outside this route
Consider a supplied base mode of 0640 for a file that may need an additional reader. The calculator renders rw-r-----: owner read and write, group read, other none. That is the complete statement supported by its inputs. It neither identifies the auditor nor offers a fourth class in which to place that identity.
Preserve this base-mode record while ACL work occurs elsewhere. If the external process later reports a different mode, decode it again and compare each class. Do not paste an ACL command into the mode field or assume the command preview incorporates named entries. It always represents only the numeric mode currently shown.
Worked example: keep the base mode readable while ACL work happens elsewhere
Other ACL families, remote filesystem rules, and mount support are not established by these sources. The calculator does not detect the storage type, mounted options, operating system, or availability of ACL operations. A missing ACL view is therefore an implementation boundary, not evidence that the underlying object lacks richer access controls.
Mandatory policy, capabilities, ownership, and process identity are likewise separate. Even complete knowledge of the base mode cannot replace those inputs. Report the mode conversion as one layer and label every unobserved layer explicitly. This prevents a clean rwx display from being mistaken for a complete authorization analysis.
Other ACL models and mount support are not inferred
When three classes are sufficient, the calculator gives a precise, reversible account of them. When they are not, keep that base account readable rather than forcing a named exception into the other class. Octal, symbolic, and checkbox views should agree on the same owner, group, other, and special-bit value.
The stopping rule is simple: use this route for base mode arithmetic and external, authoritative tools for ACL state. Never infer named entries, masks, inheritance, or filesystem support from rwx alone. A careful review combines those separate evidence sources without pretending the calculator implements access-control structures that its source code does not contain.