Back to AnthonyRawlings.com
Apps & Experiments

Linux Permissions Simulator

Change a mode, choose a user, and work through the access checks.

A simplified discretionary access control (DAC) model for ordinary, unprivileged users. No commands run and no files change. Values stay in this tab and reset on reload.

Explore permissions

Enter 3 or 4 octal digits (0–7). The optional first digit holds special bits. Each permission digit adds read = 4, write = 2, execute/search = 1.

Owner
Group
Other
Special bits

Whose access?

Alice: staff. Bob: guests, plus supplementary staff. Carol: guests. These names stand for distinct user and group IDs.

    Exactly one class applies: owner first, otherwise a matching primary or supplementary group, otherwise other. Permissions are neither combined nor retried in a more permissive class.

    Check your understanding

    Each question is independent of the explorer. Assume no additional enforcement constraints unless stated.

    Enable JavaScript to load the exercises.

    What the bits mean

    Files: read accesses contents; write modifies contents; execute is a permission check for execution. An execute bit alone does not make a file a runnable program.

    Directories: read lists names; execute means search/traverse, including lookup of a known name. Write plus search permits creating or removing entries. Reading a child’s contents also needs that child’s read permission. Removing a file entry is controlled by its parent directory, even if the file itself is read-only.

    setuid and setgid: on eligible executable files these can change the effective user or group ID at execution. They do not grant read or write access here. Linux ignores them on scripts; mount options and other restrictions can suppress them. Directory setgid makes new children inherit the directory’s group and new subdirectories inherit setgid. Directory setuid has no standard Linux effect. This trainer displays these bits but does not simulate process credentials or file creation inheritance.

    Sticky: on a directory, removing or renaming an entry is restricted to the entry owner, directory owner, or a suitably privileged process, in addition to normal permissions. It has no useful access-control effect on regular files in this Linux model. Lowercase s/t includes execute; uppercase S/T means the special bit is set without the corresponding execute bit.

    Limits of the model

    Real access also depends on ACLs, SELinux and other security modules, root and capabilities, mount flags (including read-only, noexec and nosuid), immutable attributes, filesystem behavior and process credentials. Root is deliberately not simulated as “always allowed.” We model new access by path, not already-open file descriptors, symlinks, umask, chmod/chown authorization, or rename across directories. Editing ownership here changes a hypothetical object only.

    References: Linux inode permissions, path resolution, execution rules, removing entries.