Users, Groups, and the UID Namespace | Operating Systems

UID and GID

Every UNIX process carries two user identifiers and two group identifiers:

Identifier	Where it lives	Meaning
Real UID	PCB	The user who launched the process
Effective UID	PCB	Determines permission checks. Usually equals the real UID; differs when running a SetUID programme
Real GID	PCB	The primary group of the launching user
Effective GID	PCB	Determines group permission checks. Usually equals the real GID

Additionally, a process may have a list of supplementary GIDs (groups the user is a member of). Permission checks test the effective UID and all effective GIDs (primary + supplementary).

The kernel cares about numbers, not names

The kernel identifies users and groups by integer IDs, not string names. The root user is UID 0; this privilege is hard-coded in the kernel — any process with effective UID 0 bypasses permission checks and can execute privileged instructions via system calls.

The mapping between names and numbers lives in user-space databases: /etc/passwd (users) and /etc/group (groups). The kernel never reads these files; user-space utilities (login, id, ls -l) consult them to display human-readable names.

A critical Tripos insight: changing root’s UID from 0 to 1000 in /etc/passwd means the name “root” maps to UID 1000, and UID 0 is now unnamed. The access matrix does not change — UID 0 still has all permissions. But logging in as “root” now gives you UID 1000, which has no special privileges. Administration becomes nearly impossible unless sudo or another mechanism is available.

Groups

A UNIX user belongs to one primary group (recorded in /etc/passwd) and zero or more supplementary groups (recorded in /etc/group). Each file has one owning user and one owning group.

Groups are the mechanism for sharing beyond the owner. If you want Alice and Charlie (but not others) to read a file, you create a group alice_charlie and assign the file to that group with g=r--.

Only one group can be associated with a given file at a time. For more complex sharing, use ACLs (POSIX ACLs extend the traditional 9-bit model with setfacl/getfacl).

Creating permission patterns (Tripos style)

Given a required permission pattern, the administrator must decide ownership and group membership:

Pattern 1: readable and writable by root and alice, readable by bob.

Create group gbob = {bob}.
File ArwBr owned by alice, group gbob, permissions u=rw, g=r, o= → 640.
Or: owned by bob, group galice, u=r, g=rw, o= → 460.

Pattern 2: readable and writable by root and bob, readable by any user.

File owned by bob, any group, permissions u=rw, g=r, o=r → 644.
Or: owned by anyone, group gbob, permissions g=rw, o=r → 064.

Pattern 3: owned by alice but readable and writable only by root.

File owned by alice, any group, permissions 000.
Root bypasses permissions and can read/write; alice owns it but cannot access it (permissions deny even the owner). Alice can chmod it back since she owns it.

Summary

The kernel uses numeric UID/GID; names are user-space conventions.
UID 0 = root privilege is hard-coded; changing the name’s mapping does not change the privilege.
Groups enable sharing; each file has exactly one group.
Permission patterns on Tripos questions are constructed by choosing ownership, group membership, and a 9-bit permission mask.