Understanding Linux Process Permissions: Real, Effective, and Saved UID Explained

Basic Concepts

User In a multi‑tasking Linux system, a user is the credential that obtains resources.

Permission Permissions control a user’s access to resources (CPU, memory, files, etc.) and are typically split into authentication and authorization steps.

Process A process is the basic concept of any multitasking OS, defined as an instance of a program execution. Each process acts as a proxy for the user, carrying the user’s identity when performing operations.

Process Permission A process must carry the identity of the user that started it; only then can it perform legitimate operations.

Observing User Identity in the Login Process

When Linux boots, init forks a child to run /sbin/getty, which waits for a login. After the user enters credentials, the child execs /bin/login, which validates the user via /etc/passwd and /etc/shadow. If successful, login execs the user’s default shell (e.g., bash); the shell process’s effective UID is set to the user’s UID, and any child processes inherit this effective UID.

Real, Effective, and Saved Set User IDs

Running cat /proc/<PID>/status shows four IDs: real UID, effective UID, saved set UID, and filesystem UID. The first three are described below.

Real UID The UID of the user who started the process; usually the UID used at login and inherited by child processes.

Effective UID The UID that the kernel checks when a process accesses a file. It may differ from the real UID, especially when a set‑uid executable is used. For example, /usr/bin/passwd has the set‑uid bit set so that its effective UID becomes root when executed.

Saved Set UID A buffer that stores the effective UID at exec time; non‑root users can restore the effective UID to either the real UID or the saved set UID using setuid(), but cannot change it to an arbitrary UID.

Linux decides access rights based on the effective UID (and effective GID).

How the Shell Executes External Commands

External commands are executable files located somewhere in the filesystem. The execution steps are:

Shell calls fork() to create a child process.

The child searches the directories listed in PATH for the command (unless the command name contains a slash).

The child uses an exec family function to replace its image with the found program.

When the child exits, the original shell continues reading commands.

Example: cat test.log reads a file. The user nick has real UID 1000; /bin/cat is owned by root but is executable by everyone. After fork(), the child’s effective UID is 1000, matching the file’s owner, so the read succeeds.

Changing Effective UID with set‑uid

Creating a file root.log with mode 640 makes it readable only by root. By setting the set‑uid bit on /bin/cat ( chmod 4755 /bin/cat), the cat process runs with effective UID root, allowing it to read root.log. Remember to restore the original permissions afterwards.

sudo chmod 4755 /bin/cat
# ... run cat root.log ...
sudo chmod 755 /bin/cat

Shell Script Execution

Running a script (e.g., /bin/bash ./test.sh) also involves fork(). The child then exec() s the interpreter specified by the script’s shebang line (e.g., #!/bin/bash), passing the script file as an argument.

Summary

File permissions are static, but processes are dynamic; they combine the user identity they carry with the operations they perform, enabling Linux’s permission management.