Developer tools · Chmod calculator
What chmod cannot express: capabilities, immutable files and MAC
· Background
chmod unix access-control
Mode bits are one of several layers that decide whether an operation succeeds. This post introduces the others (file capabilities, chattr flags, SELinux and AppArmor) and how to recognise each one's denial.
Root cannot write a 644 file — the mode says yes, chmod changes nothing, and the error persists
A mode may permit an operation while the operation still fails. The calculator decodes 644 as rw-r--r--, meaning the owner can read and modify a regular file while group and other can read it. That settles only the supplied traditional bits. It proves neither process ownership, path identity, nor the absence of another enforcement layer.
The sources name several unmodeled controls: capabilities, immutable attributes, mandatory access policy, mount flags, namespaces, syscall filters, ACLs, and ownership. Re-entering a mode or generating another chmod command reveals nothing about them. First verify octal, symbolic, and matrix agreement; if failure persists, gather evidence from the environment instead of widening chmod guesses.
A mode-compatible operation can still fail for layers this tool cannot see
The calculator models no ordering among external controls. Its entire data model is an integer from octal 0000 through 7777, expanded into owner, group, other, setuid, setgid, and sticky booleans. Explanations use that value and target type. No kernel decision path, security-module sequence, or syscall result enters the calculation.
That limitation makes the page a controlled first step. Confirm the mode, distinguish traversal from execution, and note special-bit letters. Article 501 adds ownership and parent-directory execute as nearby checks. Beyond those, these sources provide no diagnostic ranking among ACLs, mandatory policy, mounts, attributes, namespaces, capabilities, or filters. A compatible mode only narrows the question.
The calculator does not model ordering among external enforcement layers
File capabilities fall outside the available evidence. The implementation contains no capability names, data parser, inspection command, or account of their interaction with setuid. It can encode setuid as 4000 and explain an executable regular file. That should not become a comparison with finer-grained privilege systems that this repository neither models nor documents.
What the page proves is concrete. Mode 4755 becomes rwsr-xr-x, its summary names setuid, and assignments append u+s. Mode 4644 uses uppercase S because owner execute is absent, exposing a combination called almost always mistaken. Tests establish those mode facts; external tools must determine whether capabilities exist, permit access, or offer a better design.
File capabilities are outside the source set
Immutable and append-only attributes are also absent from the model. The calculator neither reads filesystem attributes nor recognizes commands for changing them. Its matrix contains rwx for owner, group, and other, plus three special bits. A visible write bit therefore cannot guarantee a successful write, and repeatedly toggling it cannot diagnose an attribute the page never observed.
Keep the distinction operational. If 644 renders correctly, owner write exists in the traditional mode; that is representation evidence, not a completed write. The page does not open the safely quoted display path or run its generated command. When sufficient bits accompany a real failure, inspect the actual object and system rather than attributing unobserved state.
Immutable and append-only attributes are outside the source set
Mandatory access-control contexts, profiles, and logs are not parsed here. The sources mention SELinux and AppArmor only as examples of decisions the calculator cannot observe. They provide no context syntax, policy semantics, log format, or diagnostic command. Mode alone therefore cannot attribute a denial to either system; evidence must come from the enforcing environment.
The file-or-directory selector reinforces this boundary. It changes verbs such as run, list, create, delete, enter, and reach, but neither alters the integer nor reads a policy label. A 755 program and directory share rwxr-xr-x while describing different ordinary actions. Neither explanation predicts mandatory-policy outcomes, so retain the verified mode and consult platform logs.
Mandatory access-control contexts and logs are outside the source set
A supplied mode cannot reveal mount options. The calculator accepts octal or symbolic text and an optional path used only for command display. It never opens that path, identifies its mount, or reads configuration. The sources list read-only, no-execute, and no-setuid behavior as external concerns, but provide no platform detail for diagnosing those policies.
Generated text may include an octal mode, quoted path, and displayed -R flag, yet none proves a filesystem will honor the request. Even a special-bit value that round-trips perfectly may be ineffective under unseen rules. Treat the command as a review artifact, then verify the target filesystem before claiming permissions changed or execution became possible.
Mount options are not discovered from a supplied mode
Namespaces and syscall filters appear nowhere in the mode model. The inputs contain no process identity, container context, syscall list, or runtime configuration. The page cannot know whether a process sees the same path, reaches the expected object, or has a call filtered. Those questions differ fundamentally from adding 4, 2, and 1 within permission triples.
Do not infer runtime mechanisms from a successful conversion. Validation covers malformed octal digits, symbolic length, and misplaced letters. A valid result means only that text maps to a representable mode; it does not validate an execution environment. Because generated shell text is inert, namespace and filter analysis still requires runtime evidence absent from these sources.
Namespaces and syscall filters are not represented
Start with mode because it is compact and easy to rule in or out. Translate the value, inspect each class, distinguish file from directory, and expose any special-bit prefix. Agreement among octal, symbolic, matrix, summary, and explanation makes the traditional question well formed. It may reveal a missing or excessive bit, not exclusive authority.
Continue only with evidence from the real system. Ownership, ACLs, attributes, mandatory policy, mounts, capabilities, namespaces, filters, and application rules are not discovered here. The preview neither reads nor changes a file. The disciplined conclusion is narrow: settle supplied-mode arithmetic locally, then investigate external enforcement instead of cycling through broader chmod values without knowing the denial.