Archive Format Limitations

The cpio -c and the cpio -H crc commands support the full range of UIDs and GIDs. Other archive formats have restrictions because the space allocated in the header to contain the UID and GID is not large enough to contain the extended range of UIDs and GIDs.

In general, if the archive format does not permit the correct UID or GID to be saved into the archive, the archiver will use a UID or GID of nobody, clear the relevant setuid or setgid bit, and continue.

If the UID or GID of a file is larger than 2097152 and is archived using the USTAR format of tar, pax, or cpio, the UID or GID field is set to nobody. No error message is printed in this situation because the user name and group name information encoded in this format is used to restore the file ownership, and the stored UID and GID information in the header is usually ignored.

See pax(1), tar(1), ar(1) and cpio(1) for further details.

SunOS 4.x to SunOS 5.x Migration Issues

As stated previously, the nobody user and group (60001) and the noaccess user and group (60002) retain the same UIDs and GIDs as previous Solaris releases.

SunOS 4.x systems support UIDs up to 65533, which means users with UIDs of 60001 and 60002 are valid on these systems. Change these UIDs when moving to the Solaris 2.x release, otherwise users with these UIDs will conflict with the default value of these UIDs.

To reserve the old values of 65534 on SunOS 4.x systems, a new user nobody4 set to UID 65534 and group name nogroup4 set to GID 65534 are provided in the Solaris 2.5.1 release.

---

Caution - If systems running releases earlier than the SunOS 4.1 release have UIDs greater than 65535 in their local or NIS passwd files, the associated username will be able to log into the system as root. Therefore, UIDs greater than 65535 should not be used in an environment where there are machines still running a release earlier than the SunOS 4.1 release. This bug (bug ID 1008472) was fixed in the SunOS 4.1 release.

---

x86: Restrictions When Mounting System V File Systems

An x86 system running the Solaris 2.x release can mount but not create System V file systems. If an x86 system running the Solaris 2.5.1 release attempts to create an inode owned by a user with a large UID or GID on a mounted System V file system, the System V file system returns an EOVERFLOW error.

Some System Databases Grow Larger

Certain system databases are indexed by UID. For example, the per file system quota database and the "last login" database held in /var/adm/lastlog. While these files have always been "holey", if large UIDs are used, the size of these files can become very large too. This may in turn cause administrative problems with backing up and copying the databases. The ufsdump and ufsrestore commands know how to deal with "holey" files correctly.

Summary of Large UID/GID Limitations

Table 2-2 provides a summary of UID/GID limitations for UIDs or GIDs over 60000.

Table 2-2

A UID or GID Of ...	Limitations
60003 or greater	· Is unsupported in the Solstice AdminSuite 2.1 software but supported in Solstice AdminSuite 2.2 software. · Users in this category logging into systems running previous Solaris releases and the NIS or files name service will get a UID and GID of nobody.
65535 or greater	· SunOS 4.x systems running the NFS version 2 software will truncate UIDs in this category to 16 bits, creating possible security problems. · Users in this category using the cpio command (using the default archive format) to copy files will see an error message for each file and the UIDs and GIDs will be set to nobody in the archive. · SPARC systems: Users in this category running SunOS 4.x-compatible applications will see EOVERFLOW returns from some system calls, and their UIDs and GIDs will be mapped to nobody. · x86 systems: Users in this category on x86 systems running SVR3-compatible applications will probably see EOVERFLOW return codes from system calls. · x86 systems: If users in this category attempt to create a file or directory on a mounted System V file system, the System V file system returns an EOVERFLOW error.
100000 or greater	· The ps -l command displays a maximum five-digit UID so the printed column won't be aligned when they include a UID or GID larger than 99999.
262144 or greater	· Users in this category using the cpio command (using -H odc format) or the pax -x cpio command to copy files will see an error message returned for each file, and the UIDs and GIDs will be set to nobody in the archive.
1000000 or greater	· Users in this category using the ar command will have their UIDs and GIDs set to nobody in the archive.
2097152 or greater	· Users in this category using the tar command, the cpio -H ustar command, or the pax -x tar command will have their UIDs and GIDs set to nobody.

Table 2-2 (Continued)

A UID or GID Of ...	Limitations
67108864 or greater	· The quota database exceeds the two-Gbyte maximum file size in the Solaris 2.5.1 release. Above this limit, users cannot be assigned file system quotas.
76695844 or greater	· The "last login" database exceeds the two-Gbyte maximum file size in the Solaris 2.5.1 release. Users with UIDs above this limit are not informed of their last login time. · Password aging does not work for these users.
100000000 or greater	· The column alignment of the numeric forms of ls and find output become ragged, which may break shell scripts or other commands depending on the column output format.