Unix-like operating systems identify a user within the kernel by a value called a user identifier, often abbreviated to user ID or UID. The UID, along with the group identifier (GID) and other access control criteria, is used to determine which system resources a user can access. The password file maps textual user names to UIDs, but in the kernel, only UIDs are used. UIDs are stored in the inodes of the Unix file system, running processes, tar archives, and the now-obsolete Network Information Service. In POSIX-compliant environments, the command-line command
id gives the current user's UID, as well as more information such as the user name, primary user group and group identifier (GID).
The POSIX standard introduced three different UID fields into the process descriptor table, to allow privileged processes take on different roles dynamically:
Effective user ID
The effective UID (
euid) of a process is used for most access checks. It is also used as the owner for files created by that process. The effective GID (
egid) of a process also affects access control and may also affect file creation, depending on the semantics of the specific kernel implementation in use and possibly 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 implement options for selecting at
mount time whether BSD or AT&T semantics should be used regarding group ownership of newly created files.
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
euid is root. Whenever the
euid is changed, the change is propagated to the
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.
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.
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. Since child processes inherit the credentials from the parent, they can signal each other.
POSIX requires the UID to be an integer type. Most Unix-like operating systems represent the UID as an unsigned integer. The size of UID values varies amongst different systems; some UNIX OS's[which?] used 15-bit values, allowing values up to 32767, while others such as Linux (before version 2.4) supported 16-bit UIDs, making 65536 unique IDs possible. The majority of modern Unix-like systems (e.g., Solaris-2.0 in 1990, Linux 2.4 in 2001) have switched to 32-bit UIDs, allowing 4,294,967,296 (232) unique IDs.
The Linux Standard Base Core Specification specifies that UID values in the range 0 to 99 should be statically allocated by the system, and shall not be created by applications, while UIDs from 100 to 499 should be reserved for dynamic allocation by system administrators and post install scripts.
Some POSIX systems allocate UIDs for new users starting from 500 (OS X, Red Hat Enterprise Linux), others start at 1000 (openSUSE, Debian). On many Linux systems, these ranges are specified in
useradd and similar tools.
Central UID allocations in enterprise networks (e.g., via LDAP and NFS servers) may limit themselves to using only UID numbers well above 1000, to avoid potential conflicts with UIDs locally allocated on client computers. NFSv4 can help avoid numeric identifier collisions, by identifying users (and groups) in protocol packets using "user@domain" names rather than integer numbers, at the expense of additional translation steps.
- 0: The superuser normally has a UID of zero (0).
- −1: The value
(uid_t) -1is reserved by POSIX to identify an omitted argument.
- Nobody: Historically, the user “nobody” was assigned UID
-2by several operating systems, although other values such as 215−1 = 32,767 are also in use, such as by OpenBSD. For compatibility between 16-bit and 32-bit UIDs, many Linux distributions now set it to be 216−2 = 65,534; the Linux kernel defaults to returning this value when a 32-bit UID does not fit into the return value of the 16-bit system calls. An alternative convention assigns the last UID of the range statically allocated for system use (0-99) to nobody: 99.
- Sticky bit
- Group identifier
- Process identifier
- File system permissions
- Open (system call)
- Mount (Unix)
- FAT access rights
- Kerrisk, Michael. The Linux Programming Interface. No Starch Press, 2010, p. 171.
- LSB 3.0, Section 9.3: UID Ranges
- FreeBSD Porter's Handbook, Section 6.26: Adding Users and Groups