Mastering Linux File and Process Permissions: chmod, setuid, and Sticky Bit Explained

Below are examples of user and group entries (first five lines of /etc/passwd and /etc/group); the password field in /etc/shadow is encrypted and omitted.

$ cat /etc/passwd | head -n 5

root:x:0:0:root:/root:/bin/bash

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin

bin:x:2:2:bin:/bin:/bin/sh

sys:x:3:3:sys:/dev:/bin/sh

sync:x:4:65534:sync:/bin:/bin/sync

$ cat /etc/group | head -n 5

root:x:0:

daemon:x:1:

bin:x:2:

sys:x:3:

adm:x:4:miracle

The first character of the permission string indicates file type (e.g., - for regular file, d for directory). The next nine characters are the permission bits rwxr-xr-x , representing owner, group, and others.

For the file /usr/bin/qemu-i386, the permission string shows that the owner has read, write, and execute rights, while the group and others have read and execute rights.

Numeric modes use octal notation: 755 corresponds to rwxr-xr-x. Special bits replace the execute position: s for set‑user‑ID (owner), s for set‑group‑ID (group), and t for the sticky bit (others). To set these, prepend the appropriate values (4 for owner s, 2 for group s, 1 for others t). For example, 1775 yields rwxrwxr‑t.

Process Permission Control Information

Each process has several IDs that affect file access:

effective user ID (euid): the UID used for permission checks.

effective group ID (egid): the GID used for group permission checks.

real user ID (ruid): the UID of the user who started the process.

real group ID (rgid): the GID of the user who started the process.

saved set‑user‑ID: a copy of the euid.

saved set‑group‑ID: a copy of the egid.

Tools like ps or top can display euid and ruid for each process.

Process File‑Access Strategy

The euid is usually the same as the ruid.

If an executable has the set‑user‑ID bit, executing it changes the process euid to the file’s owner UID.

The saved set‑user‑ID is copied from the euid.

A process can access a file with the owner’s permission bits only when its euid matches the file’s owner UID; group permissions work analogously with egid.

Effect of exec on IDs

ruid never changes.

saved set‑user‑ID always comes from the current euid.

euid becomes the file’s owner UID if the set‑user‑ID bit is set; otherwise it remains unchanged.

Examples

Listing /usr/bin/sudo shows rwsr-xr-x:

$ ls -l /usr/bin/sudo

-rwsr-xr-x 1 root root 71288 Feb 28 2013 /usr/bin/sudo

Here, the owner (root) has read, write, and set‑user‑ID permissions, the group has read and execute, and others have read and execute. When a normal user runs sudo, the “x” from others allows execution, and the “s” grants the process temporary root privileges.

For the /tmp directory, the sticky bit appears as drwxrwxrwt:

$ ls -ld /tmp

drwxrwxrwt 25 root root 12288 Sep 20 09:09 /tmp

The sticky bit (t) ensures that users can only delete or rename files they own, even though the directory is world‑writable.

set‑user‑ID and saved set‑user‑ID in the man Program

The man command may be installed with set‑user‑ID or set‑group‑ID. When executed, the process IDs evolve as follows:

real UID = invoking user’s UID; effective UID = man’s UID; saved set‑user‑ID = man’s UID.

The man program accesses its configuration files using the effective UID (man).

When man runs a sub‑command (e.g., !bash), it calls setuid(getuid()), changing only the effective UID back to the invoking user while the saved set‑user‑ID remains the man UID.

After the sub‑command finishes, man restores its effective UID with setuid(euid), where euid is still the man UID, because the saved set‑user‑ID matches.

This mechanism lets man temporarily gain extra privileges to read protected files, then safely drop them while the user’s commands run with normal privileges.