OTOthoTools

Permission Inspector

Explain octal permissions
Resultsymbolic
rwxr-x---
  • No critical issue detected

Introduction

The Permission Inspector decodes an octal mode (for example 0750) into its symbolic form and flags the bits that most often matter in security reviews: world-writable permissions and the setuid bit.

Octal modes are three or four digits where each digit is a sum of read (4), write (2) and execute (1) for one class of user: owner, group and others. A leading fourth digit encodes special bits: setuid (4), setgid (2) and sticky (1).

Objective

  • Translate any three- or four-digit octal mode into rwx symbolic notation.
  • Identify the special bits (setuid, setgid, sticky) when present.
  • Flag world-writable permissions as high severity and setuid as a warning.

Inputs

  • A three- or four-digit octal mode, for example 0750 or 644.
  • Digits must be 0–7; letters or symbols are rejected.

How it works

The value is padded to four digits (0750 becomes 0750, 644 becomes 0644). Each digit is decomposed into its read/write/execute bits: for example 7 = rwx, 5 = r-x, 0 = ---.

The first digit maps to the special bits: 4 adds suid, 2 adds sgid, 1 adds sticky.

If the "others" class has write permission (any 2, 3, 6 or 7 in the last digit), the tool reports a high finding: any local user can modify the object. If setuid is set, a warning asks you to verify ownership and integrity.

Testable example

Try it — the analysis runs locally in your browser.

Example

Mode: 4755

Expected output

Symbolic: suid rwxr-xr-x
High: SUID is set. Verify ownership and executable integrity.
Note: the owner and group classes are not writable by others.

Reading the output

  • The symbolic line tells you exactly who can read, write and execute.
  • A world-writable file or directory (last digit 2, 3, 6 or 7) means any local user can change it — usually a mistake unless it is a deliberately shared directory such as /tmp.
  • setuid executables run with the file owner's privileges; a compromised setuid binary is a privilege-escalation path, so ownership must be root and the binary must be trustworthy.

Risks

  • World-writable files allow tampering by any local account, including a compromised one.
  • An unexpected setuid bit on a non-root-owned binary is a classic privilege-escalation vector.
  • A sticky bit on /tmp is normal; a sticky bit elsewhere may be accidental.

Limitations

  • The tool interprets a mode, not a real file — it cannot tell you the actual owner or group.
  • It does not consider ACLs (setfacl), which override the traditional rwx model.
  • Special bit warnings depend on context; the tool cannot know whether a setuid binary is intentional.

Official references

FAQ

What do the special bits do?

setuid makes a program run with the file owner's identity (typically root); setgid does the same for the group, and on directories it makes new files inherit the directory's group; the sticky bit on a directory restricts deletion to the file owner (as on /tmp).

Why is 644 often fine for files but not 666?

644 gives the owner write access and everyone else read-only. 666 makes the file writable by everyone — any local user could replace or alter it.

Does the tool check the real file?

No. Paste a mode to understand it; use ls -l or stat on the real file when auditing your system.