Unix-like operating systems identify a user by a value called auser identifier, often abbreviated touser ID orUID. The UID, along with thegroup identifier (GID) and other access control criteria, is used to determine which system resources a user can access. Thepassword file maps textual user names to UIDs. UIDs are stored in theinodes of theUnixfile system, running processes,tar archives, and the now-obsoleteNetwork Information Service. InPOSIX-compliant environments, theshell commandid 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 to take on different roles dynamically:
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 themount options used. According toBSD Unix semantics, the group ownership given to a newly created file is unconditionally inherited from the group ownership of the directory in which it is created. According toAT&TUNIX System V semantics (also adopted byLinux variants), a newly created file is normally given the group ownership specified by theegid of the process that creates the file. Most filesystems implement a method to select whether BSD or AT&T semantics should be used regarding group ownership of a newly created file; BSD semantics are selected for specific directories when the S_ISGID (s-gid) permission is set.[1]
Linux also has a file system user ID (fsuid) which is used explicitly for access control to the file system. It matches theeuid unless explicitly set otherwise. It may beroot's user ID only ifruid,suid, oreuid is root. Whenever theeuid is changed, the change is propagated to thefsuid.
The intent offsuid is to permit programs (e.g., theNFS server) to limit themselves to the file system rights of some givenuid without giving thatuid permission to send them signals. Since kernel 2.0, the existence offsuid is no longer necessary because Linux adheres toSUSv3 rules for sending signals, butfsuid remains for compatibility reasons.[2]
The saved user ID is used when a program running with elevated privileges needs to do some unprivileged work temporarily; changingeuid from a privileged value (typically0) to some unprivileged value (anything other than the privileged value) causes the privileged value to be stored insuid. Later, a program'seuid can be set back to the value stored insuid, so that elevated privileges can be restored; an unprivileged process may set itseuid to one of only three values: the value ofruid, the value ofsuid, or the value ofeuid.
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 privileges may signal another process only if the sender'sruid oreuid matches receiver'sruid orsuid. Because achild process inherits its credentials from its parent, a child and parent may signal each other.
POSIX requires the UID to be aninteger 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[citation needed], while others such as Linux (before version 2.4) supported16-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 to32-bit UIDs, allowing 4,294,967,296 (232) unique IDs.
TheLinux 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.[3]
Debian Linux not only reserves the range 100–999 for dynamically allocated system users and groups, but also centrally and statically allocates users and groups in the range 60000-64999 and further reserves the range 65000–65533.[4]
Systemd defines a number of special UID ranges, including[5]
OnFreeBSD, porters who need a UID for their package can pick a free one from the range 50 to 999 and then register the static allocation.[6][7]
Some POSIX systems allocate UIDs for new users starting from 500 (macOS,Red Hat Enterprise Linux till version 6), others start at 1000 (Red Hat Enterprise Linux since version 7,[8]openSUSE,Debian[4]). On many Linux systems, these ranges are specified in/etc/login.defs, foruseradd and similar tools.
Central UID allocations in enterprise networks (e.g., viaLDAP andNFS servers) may limit themselves to using only UID numbers well above 1000, and outside the range 60000–65535, to avoid potential conflicts with UIDs locally allocated on client computers. When new users are created locally, the local system is supposed to check for and avoid conflicts with UID's already existing on NSS'[9]
OS-level virtualization can remap user identifiers, e.g. usingLinux namespaces, and therefore need to allocate ranges into which remapped UIDs and GIDs are mapped:
The systemd authors recommend thatOS-level virtualization systems should allocate 65536 (216) UIDs per container, and map them by adding an integer multiple of 216.[5]
(uid_t) -1 is reserved by POSIX to identify an omitted argument.[11]-2 by several operating systems, although other values such as 215−1 = 32,767 are also in use, such as byOpenBSD.[12] 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.[13]Fedora Linux assigns the last UID of the range statically allocated for system use (0–99) to nobody: 99, and calls 65534 insteadnfsnobody.NFSv4 was intended to help avoid numeric identifier collisions by identifying users (and groups) in protocol packets using textual “user@domain” names rather than integer numbers. However, as long as operating-system kernels and local file systems continue to use integer user identifiers, this comes at the expense of additional translation steps (using idmap daemon processes), which can introduce additional failure points if local UID mapping mechanisms or databases get configured incorrectly, lost, or out of sync. The “@domain” part of the user name could be used to indicate which authority allocated a particular name, for example in form of
But in practice many existing implementations only allow setting the NFSv4 domain to a fixed value, thereby rendering it useless.
chmod(1) – Solaris 11.4 User Commands ReferenceManual