From Wikipedia, the free encyclopedia - View original article
|This article does not cite any references or sources. (December 2009)|
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, ranging between 0 and 32767, with the following restrictions:
The UID value references users in the /etc/passwd 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).
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
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.
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.
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.
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.