Hubbry Logo
User identifierUser identifierMain
Open search
User identifier
Community hub
User identifier
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
User identifier
User identifier
User identifier
View on Wikipedia
from Wikipedia

In Unix-like operating systems, a user identifier (often abbreviated to user ID or UID) is a value used to identify a user. 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).

Process attributes

[edit]

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

[edit]

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

[edit]

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

[edit]

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. 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

[edit]

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

[edit]

Type

[edit]

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

[edit]

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

  • 60001-60513: UIDs for home directories managed by systemd-homed
  • 61184-65519 (0xef00-0xffef): UIDs for dynamic users

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.[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, 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.[note 1]

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:

  • snapd maps UIDs and GIDs into the range 524288-589823 (0x80000-0x8ffff)
  • systemd-nspawn automatic allocates of per-container UID ranges uses the range 524288-1879048191 (0x80000-0x6fffffff)[5]

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

Special values

[edit]
  • 0: The superuser normally has a UID of zero (0).[9]
  • −1: The value (uid_t) -1 is reserved by POSIX to identify an omitted argument.[10]
  • 65535: This value is still avoided because it was the API error return value when uid_t was 16 bits.
  • Nobody: Historically, the user "nobody" was assigned UID -2 by several operating systems, although other values such as 215−1 = 32,767 are also in use, such as by OpenBSD.[11] 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.[12] Fedora Linux assigns the last UID of the range statically allocated for system use (0–99) to nobody: 99, and calls 65534 instead nfsnobody.

Alternatives

[edit]

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

  • a Kerberos realm name
  • an Active Directory domain name
  • the name of an operating-system vendor (for distribution-specific allocations)
  • the name of a computer (for device-specific allocations)

But in practice many existing implementations only allow setting the NFSv4 domain to a fixed value, thereby rendering it useless.

See also

[edit]

Notes

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

User identifier

View on Grokipedia
from Grokipedia
A user identifier, often abbreviated as UID, is a unique symbol or character string employed by information systems to distinguish and recognize a specific user within the system. This identifier facilitates essential functions such as assigning access privileges, tracking user activities, and managing operations across various computing environments, including operating s, networks, and applications. In practice, UIDs can take forms like numeric integers in systems or alphanumeric security identifiers () in Windows environments, ensuring unambiguous user recognition without relying solely on human-readable names like usernames. In operating systems, which adhere to standards, the UID is typically a 32-bit ranging from to 4294967295, uniquely assigned to each user account to enforce file permissions and resource access controls in conjunction with the group identifier (GID). For instance, system users like often have predefined UIDs (e.g., for ), while regular users receive higher values starting from 1000 to avoid conflicts with system accounts. This numeric approach enhances security by allowing the kernel to perform efficient, privilege-based decisions without repeated name lookups. Beyond operating systems, user identifiers play a critical role in broader contexts like database management, web authentication, and identity management protocols (e.g., or SAML), where they enable secure, scalable user tracking while complying with privacy regulations such as GDPR by minimizing the exposure of . Effective management of UIDs, including preventing reuse and ensuring uniqueness across distributed systems, is vital to mitigate risks like or unauthorized access.

Overview and fundamentals

Definition and purpose

In Unix-like operating systems, a user identifier (UID) is a unique integer value that identifies a user account, enabling the distinction between multiple users in shared computing environments. In Unix-like systems, the UID is stored in configuration files such as /etc/passwd and serves as the fundamental mechanism by which the kernel associates processes, files, and resources with specific users. This numeric label, typically represented as an unsigned integer, replaces textual usernames internally to optimize system operations and enforce security boundaries. The primary purposes of a UID revolve around core security functions: authentication, which verifies a user's identity during login by mapping the provided credentials to the corresponding UID; authorization, which governs access to files, processes, and system resources based on the UID's associated privileges; and auditing, which attributes actions and events to individual users for logging and accountability. For instance, when a file is created, it is stamped with the UID of its owner, allowing the operating system to apply permission checks against that identifier during subsequent access attempts. The concept of user identifiers first emerged in early multi-user operating systems like during the 1960s, where identification combined elements such as person and project IDs to enable secure, shared access among users. It was formalized and simplified into a single numeric UID in Unix during the 1970s, supporting efficient resource sharing in environments. A basic example in systems is UID 0, which denotes the account () and grants unrestricted privileges, exempting it from standard access constraints.

Role in multi-user operating systems

In multi-user operating systems, such as systems, user identifiers (UIDs) play a critical role in enabling secure resource sharing among multiple concurrent users, such as in environments, servers, and mainframes. By assigning a unique numeric UID to each user account, the operating system kernel can associate processes, files, and other resources with specific users, preventing unauthorized access and ensuring that one user's activities do not inadvertently or maliciously affect others. This mechanism is foundational to multi-user setups where resources like , memory, and storage are allocated dynamically among users logging in locally or remotely. UIDs integrate seamlessly with the permission model to enforce access controls, particularly through file and directory permissions categorized for the owner (user), group, and others. In Unix systems, permissions specify read, write, and execute rights (e.g., represented as rwxr-xr-x), where the owner's UID determines full control over resources they create, while group and other categories allow controlled collaboration. This model extends to advanced mechanisms like access control lists (ACLs) in POSIX-compliant systems, which refine permissions beyond basic categories by referencing specific UIDs. For runtime checks, the effective user ID may temporarily alter permissions for processes, but the core association remains tied to the user's UID. The security benefits of UIDs stem from their enforcement of the least privilege principle, isolating users and their to minimize interference and limit potential damage from compromises. Each inherits its parent's UID, ensuring that operations are confined to authorized resources; for instance, a user's files cannot be modified by another without explicit permission, protecting and in shared environments. This isolation is vital in multi-user scenarios, where virtual memory separation and kernel enforcement prevent processes from accessing unauthorized or hardware. In practice, on a Unix server, web server processes like are typically run under a non-privileged UID, such as that of the www-data user (often UID 33 in Debian-based systems), to restrict their access to only necessary files and directories. This limits the scope of damage if the server is , as the process cannot escalate to system-wide privileges without additional mechanisms.

User ID attributes in Unix-like systems

Real user ID

The real user ID (RUID), also known as the real UID, is the user identifier assigned to a process upon its creation in operating systems, matching the UID of the user who originally invoked the process. This value represents the true owner of the process and is inherited from the during a fork operation, establishing the persistent identity of the initiating user. The RUID remains unchanged throughout the lifecycle unless explicitly modified by a privileged , such as setuid or setreuid executed with privileges, ensuring it serves as a stable reference to the original invoker even amid runtime privilege adjustments. The RUID plays a key role in system , where it is used to attribute resource consumption—such as , memory usage, and I/O operations—to the user who started the process, rather than any temporary privileged . In process mechanisms, the recorded user identifier in the file structure (e.g., the acct structure in ) corresponds specifically to the real UID, enabling accurate tracking and potential billing independent of effective privilege changes. It also acts as a fallback for determining the process's core identity in scenarios where the effective user ID has been altered, such as during via executables, allowing applications to query the original user via the . In POSIX-compliant systems, the real user ID is retrieved using the getuid() function, which returns the RUID of the calling and is always successful without setting errno. This call provides a reliable way to access the invariant user identity, supporting auditing and ownership verification without interference from dynamic permission shifts. For example, if a user with UID 1001 launches a , the 's RUID is set to 1001 at creation and persists regardless of subsequent actions, such as executing a program that temporarily elevates privileges; resource usage in accounting logs will thus be charged to UID 1001.

Effective user ID

The effective user ID (EUID), also known as the effective UID, is the user identifier that determines a process's access permissions and privileges in operating systems during runtime. It represents the identity under which the process operates for resource access and security checks, potentially differing from the real user ID after privilege adjustments. The EUID can be retrieved using the geteuid() . The EUID is modified via the setuid() system call, which sets it to a specified UID value if the process holds appropriate privileges, such as the CAP_SETUID capability in or execution of a setuid binary. This allows dynamic privilege escalation or de-escalation, enabling non-privileged users to perform authorized elevated tasks without granting full access. For instance, when a setuid program executes, the kernel sets the EUID to the file owner's UID, facilitating controlled privilege changes. In standard systems, the EUID is used by the kernel to enforce for operations like file opens via open() or program execution via exec(), where it is compared against file ownership and permissions. A practical example is the utility, a setuid-root program that temporarily sets its EUID to 0 () to update the protected /etc/shadow file with the user's new password, then reverts the EUID to the caller's real UID to minimize security risks. Linux introduces a filesystem user ID (FSUID) as a specialized variant of the EUID, dedicated exclusively to permission checks for filesystem accesses like path resolution and inode operations. The FSUID typically mirrors the EUID but can be independently adjusted using setfsuid(), providing finer-grained separation to support features like NFS server implementations without altering general process privileges. This allows processes to maintain distinct identities for file system interactions while using the EUID for other resources, such as semaphores or shared memory.

Saved set-user-ID

The saved set-user-ID (SUID) is a process credential in Unix-like systems that stores a copy of the effective user ID (EUID) as it was set during the last successful exec() call or by a privileged setuid() invocation, enabling the process to later restore that EUID without requiring superuser privileges. This mechanism preserves the original privilege level associated with a set-user-ID executable, distinguishing it from the real user ID (RUID) and allowing dynamic privilege management within the process. The primary purpose of the saved set-user-ID is to facilitate privilege bracketing, a security practice where a privileged process temporarily relinquishes elevated permissions by setting its EUID to the less-privileged RUID for routine operations, then restores the original EUID from the saved value for sensitive tasks that require higher access. This approach minimizes the exposure of elevated privileges, reducing the risk of exploitation if a vulnerability is triggered during unprivileged execution, and is essential for secure implementation of set-user-ID applications. In POSIX-compliant systems where the _POSIX_SAVED_IDS feature is defined, the saved set-user-ID is automatically set by the setuid() when the process has appropriate privileges (e.g., effective UID of 0), or explicitly managed using the setresuid() function, which allows setting the RUID, EUID, and SUID independently—provided the process possesses the CAP_SETUID capability or meets unprivileged constraints (e.g., setting to current RUID, EUID, or SUID values). Restoration occurs via calls like seteuid() or setreuid(), which can switch the EUID back to the saved value. However, not all systems fully implement this extension; historical BSD variants, such as 4.3BSD, lacked dedicated saved set-user-ID support and instead used setreuid() to swap between RUID and EUID directly for similar privilege-switching effects. A representative example is a network daemon process, which often starts with an EUID of 0 to bind to privileged ports below 1024. The daemon saves this EUID in the saved set-user-ID, drops privileges by setting the EUID to a non-root value (e.g., via setresuid() or setuid()) for accepting connections and handling non-sensitive I/O, and later restores the root EUID from the saved value for operations like user authentication or file access that require elevated permissions. This bracketing ensures the daemon operates with minimal privileges most of the time while retaining the ability to escalate securely when needed.

Conventions and implementation details

Data types and storage

In operating systems, user identifiers (UIDs) are represented using the uid_t defined in the <sys/types.h> header. According to the standard, uid_t is an arithmetic type suitable for holding user IDs, which may be signed or unsigned depending on the implementation, but without a specified minimum range. Historical Unix systems, running on 16-bit architectures like the PDP-11, limited UIDs to 16 bits, supporting values from 0 to 65535. Modern implementations, such as , define uid_t as an unsigned 32-bit integer, allowing up to approximately 4.3 billion unique users and addressing the limitations of earlier 16-bit designs. This change was formalized in the starting with version 2.4, which introduced full 32-bit UID support through new system calls like setfsuid32() to prevent overflows and enable scalability for larger environments. Although uid_t remains 32-bit even on 64-bit systems, some extensions in filesystems and network protocols (e.g., NFSv4) accommodate mappings for effectively larger identifier spaces in distributed setups. UIDs are stored in kernel structures managing processes and users. In the , they reside within the struct cred pointed to by the cred field of struct task_struct, the process control block that tracks per-process credentials including real, effective, and saved UIDs. For persistent user account information, UIDs are maintained in databases such as the /etc/passwd file, where each line's third colon-separated field holds the UID as a , or in directory services like LDAP, using the uidNumber attribute as an value. This storage ensures portability across POSIX-compliant systems, where uid_t facilitates consistent handling despite varying underlying sizes.

UID allocation ranges

In Unix-like systems, user identifiers (UIDs) are typically assigned within numerical ranges defined by standards and implementations to ensure compatibility and prevent conflicts between system and user accounts. Historical Unix systems limited UIDs to a 16-bit unsigned range of 0 to 65,535 for compatibility. Modern implementations like extend support using the 32-bit uid_t type, allowing UIDs up to 4,294,967,295 (2^32 - 1), though practical allocation often adheres to established conventions, such as those outlined in the (LSB), for interoperability. According to the (LSB), UIDs 0-99 are statically allocated for system use, 100-499 for dynamic system accounts, and 500+ for regular users, though distributions may vary these ranges. To distinguish system accounts from regular users and avoid overlap that could compromise security, UIDs are divided into reserved and allocatable ranges. UIDs from 0 to 99 are conventionally reserved for system accounts, such as (UID 0) and other privileged services, while some distributions extend this to 0-999 for additional system use. Regular user accounts are typically assigned UIDs starting from 1000 onward, ensuring that user processes cannot inadvertently access or interfere with system resources. This separation is configurable via system files like /etc/login.defs in , where parameters such as UID_MIN and UID_MAX define the boundaries for dynamic allocation. UID allocation is managed through tools like useradd or adduser, which draw from predefined pools to assign unique values automatically, often querying the Name Service Switch (NSS) for configuration and availability checks across local files, LDAP, or other backends. The process ensures sequential or lowest-available assignment within the user range, with NSS modules like files or sss handling lookups to maintain uniqueness without manual intervention. In containerized environments, such as those using Docker, UID mapping techniques remap container-internal UIDs to distinct host ranges (e.g., 100000+ for isolated namespaces) to prevent conflicts between containerized applications and the host system.

Special and reserved UIDs

In systems, UID 0 is reserved for the user, also known as the , which possesses unrestricted access to all resources and bypasses permission checks enforced by the kernel. This elevated privilege level is essential for system administration tasks, such as installing software or modifying critical files, but it introduces significant risks if compromised, as an attacker gaining access can control the entire . UID 65534, often referred to as the "nobody" or overflow UID, is a special identifier assigned to processes that require no privileges, such as certain daemons or NFS operations where client-supplied UIDs cannot be trusted. This UID is the default value for the kernel's overflowuid parameter, which maps unmapped or invalid UIDs to prevent unauthorized access while minimizing potential damage from unprivileged services like web servers in default configurations. For instance, the may run under this UID to isolate it from the filesystem. Certain ranges and values are reserved to maintain system integrity; for example, UID 65535 (or -1 in signed interpretation) is typically invalid or treated as an overflow marker in 16-bit UID contexts, though modern 32-bit implementations use 4294967295 as the unsigned equivalent for unmapped IDs. In extensions like user namespaces, negative UIDs (interpreted as high unsigned values) can represent virtual or unmapped users, allowing isolated mappings without conflicting with host UIDs. Misuse of special UIDs, particularly through set-user-ID (SUID) binaries owned by , can enable vulnerabilities, where an unprivileged user exploits a flaw to gain access. Modern security practices, such as capability bounding sets and avoiding unnecessary SUID programs, mitigate these risks by limiting the scope of privileges.

Alternatives and variations

User identifiers in Windows

In Windows operating systems, user identification relies on Security Identifiers (), which provide a mechanism for authorizing access to resources in multi-user environments, analogous to User IDs (UIDs) in systems but with a more elaborate structure suited to networked domains. A SID is a unique, variable-length value that identifies a security principal, such as a user account, group, or other , and is issued by a or upon creation. Unlike the simple numeric UIDs in Unix, SIDs are not purely numerical but formatted as strings to encode hierarchical and contextual information for robust security management. The SID consists of several components that ensure global uniqueness: a revision number (typically 1, denoting the version), an identifier (a 48-bit value specifying the issuing entity, such as 5 for NT ), one to fifteen 32-bit subauthorities (providing hierarchical context like domain identifiers), and a relative identifier (RID, the final 32-bit subauthority that uniquely distinguishes the principal within its scope, such as 500 for the built-in Administrator). This results in a string representation like S-1-5-21-3623811015-3361044348-30300820-1013, where the prefix S-1-5-21 indicates a domain user under NT , followed by domain-specific subauthorities and the RID. For local accounts, the machine's unique SID (generated at installation) forms the base, prefixed similarly but scoped to the individual system. Well-known , such as S-1-5-32-544 for the local Administrators group, remain constant across installations to identify generic principals like "Everyone" (S-1-1-0). SIDs are fundamental to Windows , appearing in access control lists (ACLs) on file systems and other securable objects to grant or deny permissions based on the principal's identity. In , domain SIDs combine a fixed domain identifier with the RID, enabling centralized management and enterprise-scale uniqueness, while security tokens generated at encapsulate the user's primary SID, supplementary group SIDs, and privileges to enforce policies throughout the session. Local SIDs, in contrast, are machine-specific and do not require domain infrastructure, supporting standalone operations. Compared to Unix UIDs, Windows offer greater complexity to accommodate distributed environments, avoiding renumbering issues during user migration by preserving original SIDs in attributes like SIDHistory, which maintains access rights without updating every ACL. This portability is particularly valuable in domain migrations, where local users' machine-based SIDs allow seamless transfer between systems without identity conflicts. SIDs are never reused, further enhancing by preventing aliasing of principals.

Approaches in other operating systems

macOS adopts a hybrid user identification system that builds upon numeric user IDs (UIDs) while incorporating Open Directory, Apple's directory services framework, to manage extended user attributes. In this setup, each user record includes a numeric UID for compatibility with standards, alongside a GeneratedUID—a (UUID) formatted as a GUID—for persistent and cross-system user tracking. This GUID enables seamless integration with cloud services such as , where it links local user data to managed Apple accounts for synchronization of contacts, calendars, and documents without relying solely on numeric IDs. Open Directory stores these attributes in a pluggable architecture, allowing extensions for enterprise environments like mapping, where attributes such as UID and GUID are configured to align macOS authentication with external directories. Linux variants, such as Android, extend traditional UID mechanisms with specialized ranges to enforce application-level isolation in mobile environments. Android assigns each installed app a unique UID starting from (typically in the range 10000–99999) to create a kernel-enforced sandbox, preventing inter-app data access and limiting privileges to the app's process and storage. This per-app UID allocation, managed by the , treats applications as distinct Unix users, enhancing security through discretionary access controls without requiring separate numeric IDs for human users. The approach prioritizes runtime isolation over shared user sessions, differing from desktop by reserving lower UIDs (0–9999) for system components and users. In mainframe operating systems like IBM , user identification diverges from numeric UIDs toward alphanumeric profiles managed by the (RACF). RACF user IDs consist of 1 to 8 alphanumeric characters (A–Z, 0–9, #, $, @), serving as keys to security profiles that define access rights rather than direct file ownership via numbers. This design emphasizes batch job security, where the USER parameter on a JOB statement specifies the RACF user ID for and during execution, enabling fine-grained control over resources in high-volume, non-interactive workloads. Unlike Unix systems, RACF maps any underlying numeric UIDs (for z/OS UNIX compatibility) to these alphanumeric IDs via dedicated profiles, focusing on enterprise-scale auditing and segregation over process-level isolation. Cloud-native systems, such as those orchestrated by , adapt user identifiers for containerized environments by mapping UIDs through pod security contexts to ensure consistent isolation across distributed nodes. In , a security context specifies the runAsUser field to set the UID under which container processes execute, allowing administrators to enforce non-root execution (e.g., UID 1000) or remap host UIDs via user namespaces for enhanced privilege separation. This UID mapping integrates with the underlying container runtime (e.g., containerd or CRI-O), where pod specifications define supplemental groups and filesystem ownership (via fsGroup) to align access controls with orchestrated workloads. The approach addresses gaps in traditional OS user management by treating UIDs as ephemeral and configurable per pod, facilitating secure multi-tenancy in container orchestration without fixed system-wide allocations.

References

  1. https://csrc.nist.gov/glossary/term/user_id
  2. https://www.indicative.com/resource/user-identification-user/
  3. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
  4. https://docs.aws.amazon.com/efs/latest/ug/API_PosixUser.html
  5. https://www.geeksforgeeks.org/linux-unix/real-effective-and-saved-userid-in-linux/
  6. https://trugman-internals.com/posts/2018-12-25-unix-uids/
  7. https://www.techtarget.com/iotagenda/definition/unique-identifier-UID
  8. https://man7.org/linux/man-pages/man5/passwd.5.html
  9. https://www.oreilly.com/library/view/practical-unix-and/0596003234/ch04s01.html
  10. https://www.scaler.com/topics/linux-uid/
  11. https://www.labouseur.com/courses/os/UNIX-Time-Sharing-System-by-Ritchie-and-Thompson.pdf
  12. https://www.multicians.org/history.html
  13. https://dl.acm.org/doi/10.1145/361011.361061
  14. https://www.ssh.com/academy/iam/user-id
  15. https://www.macs.hw.ac.uk/~hwloidl/Courses/F21CN/OSsec.pdf
  16. https://people.computing.clemson.edu/~jmarty/courses/commonCourseContent/AdvancedModule-LinuxSysAdmin/AccessControl.html
  17. https://faculty.cs.niu.edu/~berezin/330/N/access-control.html
  18. https://www.redhat.com/en/blog/user-account-gid-uid
  19. https://documentation.ubuntu.com/server/how-to/web-services/configure-apache2-settings/
  20. https://www.usenix.org/legacy/event/sec02/full_papers/chen/chen.pdf
  21. https://pubs.opengroup.org/onlinepubs/9699919799/functions/setuid.html
  22. https://man7.org/linux/man-pages/man5/acct.5.html
  23. https://pubs.opengroup.org/onlinepubs/007904975/functions/getuid.html
  24. https://pubs.opengroup.org/onlinepubs/9699919799/functions/geteuid.html
  25. https://man7.org/linux/man-pages/man7/credentials.7.html
  26. https://man7.org/linux/man-pages/man2/setuid.2.html
  27. https://man7.org/conf/meetup/privileged-programs--jambit-Kerrisk-2019-04-01.pdf
  28. https://man7.org/linux/man-pages/man2/setfsuid.2.html
  29. https://man7.org/linux/man-pages/man2/setresuid.2.html
  30. https://linux.die.net/man/3/setuid
  31. https://www.ibm.com/docs/en/zos/2.5.0?topic=functions-setuid-set-effective-user-id
  32. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
  33. https://unix.stackexchange.com/questions/191663/any-concerns-with-using-high-uid-numbers-3000-on-rhel5
  34. https://stackoverflow.com/questions/1922761/size-of-pid-t-uid-t-gid-t-on-linux
  35. https://systemd.io/UIDS-GIDS/
  36. https://www.kernel.org/doc/html/v4.15/security/credentials.html
  37. https://ldapwiki.com/wiki/Wiki.jsp?page=UidNumber
  38. https://refspecs.linuxbase.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/uidrange.html
  39. https://man7.org/linux/man-pages/man7/capabilities.7.html
  40. https://attack.mitre.org/techniques/T1548/001/
  41. https://man7.org/linux/man-pages/man7/user_namespaces.7.html
  42. https://learn.microsoft.com/en-us/windows/win32/secauthz/security-identifiers
  43. https://learn.microsoft.com/en-us/windows/win32/secauthz/sid-components
  44. https://eclecticlight.co/2024/07/31/delving-deep-into-user-accounts-in-directory-services/
  45. https://support.apple.com/guide/directory-utility/map-group-primary-gid-uid-active-directory-diru0f42005a/mac
  46. https://support.apple.com/guide/deployment/icloud-for-managed-apple-accounts-depbf9a02986/web
  47. https://source.android.com/docs/security/app-sandbox
  48. https://www.ibm.com/docs/en/zos/3.1.0?topic=security-server-racf-administrators-guide
  49. https://stackoverflow.com/questions/76640238/on-z-os-what-are-the-valid-characters-for-a-userid
  50. https://help.hcl-software.com/workloadautomation/v95/distr/src_sazos/awsszupdateracffortheagentforzosstartedtask.html
  51. https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
  52. https://learnkube.com/security-contexts
Add your contribution
Related Hubs
User Avatar
No comments yet.