Skip to content
WebsiteHosting.com

concept Linux & administration

Linux file and directory permissions

Linux mode bits select owner, group or other permissions for an operation. Directory execute means search; passing a mode-bit check alone does not prove that real access will succeed.

Latest recorded source check · P0052

What it means

Each permission digit is a sum of bits: read contributes 4, write 2 and execute 1. In 0750, the last three digits represent owner = 7, group = 5 and other = 0. Thus 7 contains all three bits, 5 contains read and execute, and 0 contains none.

The owner, group and other digits are alternatives for the basic check, not permissions to add together. On Linux, first compare the process's filesystem user ID with the file's owner ID: a match selects owner. Otherwise, group applies when the file's group matches the process's filesystem group ID or one of its supplementary groups. If neither match applies, use other. The filesystem IDs normally equal the corresponding effective IDs. Once a class is selected, this basic check does not fall back to a more permissive class.

Here, the Effective class dropdown supplies that choice directly. It does not discover or change process credentials or group membership; the model calculates only the selected class's mode-bit result.

Try it

Simulation: this is a local synthetic bit check, not a filesystem permission change. Start with Effective class = group, Octal mode = 0750 and Operation = read. Change only Octal mode to 0700, then inspect the result and its explanation. Use Compare with baseline to display the baseline and current outcomes.

Check a basic mode-bit permission

Change one condition and inspect the computed result, its cause, and the model boundary.

Simulation

No ACLs, effective IDs, supplementary groups, directory ancestors, capabilities or mount policy.

Permitted by these mode bits

The group class has octal digit 5; the read operation requires bit 4.

Check a basic mode-bit permission: supplied inputs
InputSupplied value
Effective classgroup
Octal mode0750
Operationread
Check a basic mode-bit permission: synthetic inputs

Synthetic local learning example. No account, real network, server, filesystem, credential, command or production change is accessed.

About this model

No ACLs, effective IDs, supplementary groups, directory ancestors, capabilities or mount policy.

These are bounded teaching rules. Actual behavior needs the linked subject specifications and independent observations. The examples are not live checks.

Initially: Permitted by these mode bits. The group class has octal digit 5; the read operation requires bit 4. Changing the mode to 0700 removes that bit from the selected group digit, so the result becomes denied.

Keep Effective class = group and Operation = read. Only Octal mode changes from 0750 to 0700; no credentials, path or other access policy is evaluated.

Reset restores Effective class = group, Octal mode = 0750 and Operation = read, removes input errors and clears the comparison. It does not change which FAQ answers or the About this model panel you have opened or closed.

How it works

The calculation has two stages: select the digit for the supplied class, then test whether that digit contains the required operation bit. For the baseline, group selects the middle permission digit in 0750: 5. Because 5 = 4 + 1, it contains read and execute but not write. The requested read bit is 4, so this limited check permits the read.

The selected digit matters more than how permissive the mode looks as a whole. In a separate synthetic case, Effective class = other, Octal mode = 0644 and Operation = write selects digit 4. That digit contains read but not the required write bit 2, so the result is denied. The owner's digit 6 is not part of that calculation.

Object type changes the meaning of the operation. For a regular file, read and write concern file contents, while execute concerns execution. For a directory, execute is search permission: path lookup needs it to proceed through the directory to a named entry. Reaching that entry and obtaining access to the final object are separate conditions. This is why a file's matching read bit cannot, by itself, establish that the process can open the file.

Worked example

This is a synthetic baseline, not an observation from a Linux machine.

InputValue
Effective classgroup
Octal mode0750
Operationread

Permitted by these mode bits. The group class has octal digit 5; the read operation requires bit 4.

The intermediate evidence is the selected digit, 5—not the owner's 7 or the entire number 0750. Since 5 contains bit 4, the requested operation passes this bit test.

What changes when the condition changes

Change only Octal mode from 0750 to 0700. Keep Effective class = group and Operation = read.

Denied by these mode bits. The group class has octal digit 0; the read operation requires bit 4.

The owner still has digit 7, but the selected group digit has changed from 5 to 0. The group no longer has the read bit, and the model does not borrow it from the owner's permissions. Changing this dropdown changes only the synthetic input, not a real file's mode.

In practice

On a Linux system you own or are authorized to inspect, keep the first pass read-only and limited to the failed operation and its exact path. Record whether the target is a regular file or directory, its owner, group and mode, and the credentials of the process that failed. Your interactive shell may not have the same credentials as a web server or background service.

Inspect the required ancestor directories as well as the final object. The useful observation is whether the relevant class has the required bit at each applicable check—not merely whether a familiar-looking mode appears on the final file.

  • If the selected class lacks the requested bit, that explains the denial within the basic mode-bit model.
  • If that bit is present, do not declare access successful. Path traversal or another access-control condition may still prevent it.
  • If you cannot establish the process identity, applicable class or required path permissions, the real access outcome remains unknown from this evidence.

STOP before changing permissions if the path, credentials, ACLs, mount policy or another restriction remains unexplained. Do not use 0777 or a broad recursive permission change to diagnose one denial. This page prescribes no filesystem mutation; any later change needs an authorized, object-specific plan with a recorded before-state, verification of the original operation and a rollback plan.

Limits and unknowns

The result is deliberately phrased “by these mode bits.” The Simulation does not evaluate ACLs, effective IDs, supplementary groups, directory ancestors, capabilities or mount policy. It cannot determine which class a real process should use, whether the path is reachable, or whether a real read, write or execution will succeed.

For valid offered inputs, the model returns a permitted-or-denied bit result; it does not produce a diagnosis of a real system. Missing real-world evidence remains unknown even when the local calculation is definite. If an input is reported as invalid, no calculated outcome applies until you correct it or use Reset; do not rely on an earlier result.

The initial example and explanation remain readable without JavaScript. Interactive controls require JavaScript. No machine, account, filesystem or network service is inspected.

What to carry forward

Treat a mode-bit result as one layer of access evidence. A missing bit explains the limited model's denial; a present bit does not establish successful access on a real machine. Before considering a permission change, connect the failed operation to the process's credentials, the relevant permission class and the required path traversal.

Frequently asked questions

Editorial questions, answered from the sources listed for this article.

Why do directories need execute permission?

For a directory, execute means search, not running the directory as a program. Search permission allows lookup of a known name inside it. Read permission concerns reading directory entries. These are separate checks: permission to read the names does not by itself establish permission to traverse to a child.

Are owner and group permissions combined for an owner?

No. In the basic mode-bit check, an owner uses the owner class; missing owner permissions are not filled in from the group or other digits. The check does not choose whichever class would grant access. This Simulation asks you to supply the applicable class rather than deriving it from process credentials.

Can a readable file still produce Permission denied?

Yes. Lookup can fail at an ancestor directory that the process cannot search, before access to the final file is established. Checking only the file's readable bits misses that earlier boundary. Inspect the required path components in the failing process's credential context, rather than treating the final mode as a complete diagnosis.

Does 0777 guarantee a write will succeed?

No. 0777 grants the basic read, write and execute bits to all three classes on that object, but it does not make a read-only filesystem writable or establish search access through every ancestor directory. Broadening permissions can expose the object without resolving the actual restriction; it is not a diagnostic shortcut.

Sources & model boundaries

Primary references used for this explanation. The interactive example is an educational model, not a live check.

  1. Linux chmod(2)

    DESCRIPTION and ERRORS. Mode bits, directory search permission and limits on mode changes

    Checked .

  2. Linux path_resolution(7)

    DESCRIPTION: starting point, traversal, dot components, trailing slashes; Permissions; Bypassing permission checks. Process-relative roots and path lookup, with symlink and permission qualifications; Owner match has priority; otherwise group or supplementary-group match selects group; otherwise other. Linux uses filesystem IDs. Capability exceptions remain outside the model.

    Checked .

  3. Linux credentials(7)

    Process IDs; user and group identifiers; User and group identifiers: filesystem IDs and supplementary groups. Process identity and effective credential context; not a live permission check; Filesystem IDs and supplementary groups apply to file permissions; filesystem IDs normally match effective IDs. Does not by itself provide the retained FAQ4 PID-reuse support.

    Checked .