User identifier

Last updated

Unix-like operating systems identify a user 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. 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 shell 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).

Contents

Process attributes

The POSIX standard introduced three different UID fields into the process descriptor table, to allow privileged processes to 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 to a newly created file is unconditionally inherited from the group ownership of the directory in which it is created. 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. 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]

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. [2]

Saved user ID

The saved user ID 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. [3] 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.

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 privileges may signal another process only if the sender's ruid or euid matches receiver's ruid or suid. Because a child process inherits its credentials from its parent, a child and parent may signal each other.

Conventions

Type

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[ citation needed ], 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.

Reserved ranges

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. [4]

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. [5]

Systemd defines a number of special UID ranges, including [6]

On FreeBSD, 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. [7] [8]

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, [9] openSUSE, Debian [5] ). On many Linux systems, these ranges are specified in /etc/login.defs, for 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, 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' [10]

OS-level virtualization can remap user identifiers, e.g. using Linux namespaces, and therefore need to allocate ranges into which remapped UIDs and GIDs are mapped:

The systemd authors recommend that OS-level virtualization systems should allocate 65536 (216) UIDs per container, and map them by adding an integer multiple of 216. [6]

Special values

Alternatives

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.

See also

Related Research Articles

<span class="mw-page-title-main">Operating system</span> Software that manages computer hardware resources

An operating system (OS) is system software that manages computer hardware and software resources, and provides common services for computer programs.

Linux has several filesystem drivers for the File Allocation Table (FAT) filesystem format. These are commonly known by the names used in the mount command to invoke particular drivers in the kernel: msdos, vfat, and umsdos.

Unix security refers to the means of securing a Unix or Unix-like operating system. A secure environment is achieved not only by the design concepts of these operating systems, but also through vigilant user and administrative practices.

In computing, particularly in the context of the Unix operating system and its workalikes, fork is an operation whereby a process creates a copy of itself. It is an interface which is required for compliance with the POSIX and Single UNIX Specification standards. It is usually implemented as a C standard library wrapper to the fork, clone, or other system calls of the kernel. Fork is the primary method of process creation on Unix-like operating systems.

C dynamic memory allocation refers to performing manual memory management for dynamic memory allocation in the C programming language via a group of functions in the C standard library, namely malloc, realloc, calloc, aligned_alloc and free.

In computing, the process identifier is a number used by most operating system kernels—such as those of Unix, macOS and Windows—to uniquely identify an active process. This number may be used as a parameter in various function calls, allowing processes to be manipulated, such as adjusting the process's priority or killing it altogether.

The archiver, also known simply as ar, is a Unix utility that maintains groups of files as a single archive file. Today, ar is generally used only to create and update static library files that the link editor or linker uses and for generating .deb packages for the Debian family; it can be used to create archives for any purpose, but has been largely replaced by tar for purposes other than static libraries. An implementation of ar is included as one of the GNU Binutils.

Capability-based security is a concept in the design of secure computing systems, one of the existing security models. A capability is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights. A user program on a capability-based operating system must use a capability to access an object. Capability-based security refers to the principle of designing user programs such that they directly share capabilities with each other according to the principle of least privilege, and to the operating system infrastructure necessary to make such transactions efficient and secure. Capability-based security is to be contrasted with an approach that uses traditional UNIX permissions and Access Control Lists.

The inode is a data structure in a Unix-style file system that describes a file-system object such as a file or a directory. Each inode stores the attributes and disk block locations of the object's data. File-system object attributes may include metadata, as well as owner and permission data.

In Unix and Unix-like computer operating systems, a file descriptor is a process-unique identifier (handle) for a file or other input/output resource, such as a pipe or network socket.

fstab is a system file commonly found in the directory /etc on Unix and Unix-like computer systems. In Linux, it is part of the util-linux package. The fstab file typically lists all available disk partitions and other types of file systems and data sources that may not necessarily be disk-based, and indicates how they are to be initialized or otherwise integrated into the larger file system structure.

stat (system call) Unix system call

stat is a Unix system call that returns file attributes about an inode. The semantics of stat vary between operating systems. As an example, Unix command ls uses this system call to retrieve information on files that includes:

In Unix-like systems, multiple users can be put into groups. POSIX and conventional Unix file system permissions are organized into three classes, user, group, and others. The use of groups allows additional abilities to be delegated in an organized fashion, such as access to disks, printers, and other peripherals. This method, among others, also enables the superuser to delegate some administrative tasks to normal users, similar to the Administrators group on Microsoft Windows NT and its derivatives.

Most file systems include attributes of files and directories that control the ability of users to read, change, navigate, and execute the contents of the file system. In some cases, menu options or functions may be made visible or hidden depending on a user's permission level; this kind of user interface is referred to as permission-driven.

The seven standard Unix file types are regular, directory, symbolic link, FIFO special, block special, character special, and socket as defined by POSIX. Different OS-specific implementations allow more types than what POSIX requires. A file's type can be identified by the ls -l command, which displays the type in the first character of the file-system permissions field.

File locking is a mechanism that restricts access to a computer file, or to a region of a file, by allowing only one user or process to modify or delete it at a specific time and to prevent reading of the file while it's being modified or deleted.

The following tables compare general and technical information for a number of file systems.

GVfs is GNOME's userspace virtual filesystem designed to work with the I/O abstraction of GIO, a library available in GLib since version 2.15.1. It installs several modules that are automatically used by applications using the APIs of libgio. There is also FUSE support that allows applications not using GIO to access the GVfs filesystems.

In Unix-like operating systems, a device file or special file is an interface to a device driver that appears in a file system as if it were an ordinary file. There are also special files in DOS, OS/2, and Windows. These special files allow an application program to interact with a device by using its device driver via standard input/output system calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.

systemd Suite of system components for Linux

systemd is a software suite that provides an array of system components for Linux operating systems. The main aim is to unify service configuration and behavior across Linux distributions. Its primary component is a "system and service manager" – an init system used to bootstrap user space and manage user processes. It also provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging. The name systemd adheres to the Unix convention of naming daemons by appending the letter d. It also plays on the term "System D", which refers to a person's ability to adapt quickly and improvise to solve problems.

References

  1. ↑ chmod(1)  –  Solaris 11.4 User Commands Reference Manual
  2. ↑ Kerrisk, Michael. The Linux Programming Interface. No Starch Press, 2010, p. 171.
  3. ↑ "Setuid Demystified" (PDF). Cs.berkeley.edu. Retrieved 2016-09-24.
  4. ↑ "9.3. UID Ranges". Refspecs.linuxfoundation.org. Retrieved 2016-09-24.
  5. 1 2 "Debian Policy Manual – Section 9.2.2: UID and GID classes". Debian.org. 2019-07-18. Retrieved 2019-07-26.
  6. 1 2 3 "Users, groups, UIDs and GIDs on systemd systems". GitHub . Retrieved 2020-09-26.
  7. ↑ "FreeBSD Porter's Handbook". Freebsd.org. Retrieved 2016-09-24.
  8. ↑ "Chapter 6. Special Considerations".
  9. ↑ "RHEL7 System changes". Certdepot.net. 2016-01-17. Retrieved 2017-03-22.
  10. ↑ https://systemd.io/UIDS-GIDS/ "for both allocation ranges: when an UID allocation takes place NSS is checked for collisions first, and a different UID is picked if an entry is found"
  11. ↑ "Getpwuid". Pubs.opengroup.org. Retrieved 2016-09-24.
  12. ↑ "Chown". Pubs.opengroup.org. Retrieved 2016-09-24.
  13. ↑ "NetBSD Problem Report #6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)". GnaNFSv4ts.netbsd.org. Retrieved 2016-09-24.
  14. ↑ "Namespaces in operation, part 5: User namespaces". Lwn.net. Retrieved 2016-09-24.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.