UIDs are stored in the inodes of the Unix file system, running processes, tar archives, and the now-obsolete Network Information Service.
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.
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.
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.
[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]).
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. 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.
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.