User identifier
Unix-like operating systems identify users within the kernel by an unsigned integer value called a user identifier, often abbreviated to UID or User ID. The range of UID values varies amongst different systems; at the very least, a UID represents a 15-bit integer,[citation needed] ranging between 0 and 32767, with the following restrictions:
- The superuser must always have a UID of zero (0).
- The user “nobody” traditionally got the largest possible UID (as the opposite of the superuser): 32767.
- Convention reserves UIDs from 1 to 100 for system use; some manuals recommend reserving UIDs from 101 up to 499 (Red Hat Enterprise Linux) or even up to 999 (Debian) as well.
The UID value references users in the /etc/password file. Shadow password files and Network Information Service also refer to numeric UIDs. The user identifier has become a necessary component of Unix file systems and processes. Some operating systems support 16-bit UIDs, making 65536 unique IDs possible; a modern system with 32-bit UIDs will potentially make 4,294,967,296 (232) distinct values available.
In POSIX-compliant environments the command-line command id gives the user's user identifier number as well as more information on the user account like the user name, primary user group and group identifier (GID).
Effective user ID
The effective UID (euid) of a process is the ownership assigned to files created by that process. The effective GID (egid) of a process may also affect file creation, depending on the semantics of the specific kernel implementation being used and possibly also by the mount options used. According to BSD Unix semantics, the group ownership given a newly created file is unconditionally inherited from the group ownership of the directory in which it is created. According to AT&T System 5 Unix semantics (also adopted by Linux variants) newly created files will normally be given the group ownership of the egid of the process that creates them.
Some filesystems may implement options for selecting at mount time whether BSD or AT&T semantics should be used regarding group ownership of newly created files. Refer to the pertinent specific implementation-dependent documentation for open and mount operations to learn of these nuances between implementations.
During file access, the kernel uses the effective UID and effective GID of the process to determine if it can access the file.
Saved user ID
The saved user ID (suid) is used when a program running with elevated privileges needs to temporarily do some unprivileged work: it changes its effective user ID from a privileged value (typically root) to some unprivileged one, and this triggers a copy of the privileged user ID to the saved user ID slot. Later, it can set its effective user ID back to the saved user ID (an unprivileged process can only set its effective user ID to three values: its real user ID, its saved user ID, and its effective user ID—i.e., unchanged) to resume its privileges.
File system user ID
Linux also has a file system user ID (fsuid) which is used explicitly for access control to the file system. It matches the euid unless explicitly set otherwise. It may be root's user ID only if ruid, suid, or euid is root. Whenever the euid is changed, the change is propagated to the fsuid.
The intent of fsuid is to permit programs (e.g., the NFS server) to limit themselves to the file system rights of some given uid without giving that uid permission to send them signals. Since kernel 2.0, the existence of fsuid is no longer necessary because Linux adheres to SUSv3 rules for sending signals, but fsuid remains for compatibility reasons.[1]
Real user ID
The real UID (ruid) and real GID (rgid) identify the real owner of the process and affect the permissions for sending signals. A process without superuser privilege can signal another process only if the sender’s real or effective UID matches the real or saved UID of the receiver.[1] Since child processes inherit the credentials from the parent, they can signal each other.