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 (2 32) unique IDs. The size of UID values varies amongst different systems some UNIX OS's 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. Most Unix-like operating systems represent the UID as an unsigned integer. POSIX requires the UID to be an integer type. Because a child process inherits its credentials from its parent, a child and parent may signal each other. A process without superuser privileges may signal another process only if the sender's ruid or euid matches receiver's ruid or suid. The real UID ( ruid) and real GID ( rgid) identify the real owner of the process and affect the permissions for sending signals. Later, a program's euid can be set back to the value stored in suid, so that elevated privileges can be restored an unprivileged process may set its euid to one of only three values: the value of ruid, the value of suid, or the value of euid. The saved user ID ( suid) is used when a program running with elevated privileges needs to do some unprivileged work temporarily changing euid from a privileged value (typically 0) to some unprivileged value (anything other than the privileged value) causes the privileged value to be stored in suid. 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 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. Whenever the euid is changed, the change is propagated to the fsuid. It may be root's user ID only if ruid, suid, or euid is root. It matches the euid unless explicitly set otherwise. Linux also has a file system user ID ( fsuid) which is used explicitly for access control to the file system. 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. According to AT&T UNIX System V semantics (also adopted by Linux variants), a newly created file is normally given the group ownership specified by the egid of the process that creates the file. According to BSD 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. 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.
It is also used as the owner for files created by that process. The effective UID ( euid) of a process is used for most access checks. The POSIX standard introduced three different UID fields into the process descriptor table, to allow privileged processes to take on different roles dynamically: 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). UIDs are stored in the inodes of the Unix file system, running processes, tar archives, and the now-obsolete Network Information Service.
GID DISTRIBUTION PASSWORD
The password file maps textual user names to UIDs. The UID, along with the group identifier (GID) and other access control criteria, is used to determine which system resources a user can access. Unix-like operating systems identify a user by a value called a user identifier, often abbreviated to user ID or UID. Value identifying a user account in Unix and Unix-like operating systems
0 kommentar(er)
