Large User IDs

For 10.20, HP-UX will support user and group IDs ranging from 0 (root) to a maximum of MAXINT - 1, which is equal to 2,147,483,646 or (2^ 31) -2.

The constant MAXUID, which defines the lowest integer that cannot be used as a user or group ID number, is raised from its current value of 60,000 to MAXINT. These constants have also changed:

          ===============================

          Constant              New Value

          ===============================

          ACLUNUSED               -35

          ACL_ANYGROUP            -25

          ACL_ANYUSER             -25

          ACL_FILEGROUP           -26

          ACL_FILEOWNER           -26

          ACL_NSGROUP             -36

          ACL_NSUSER              -36

          UID_EUID                -34

          UID_NOBODY              -2

          UID_RUID                -33

          UID_SUID                -32

          ===============================

The formats of the HFS and VxFS file systems will change to allow storage of these new, higher user and group ID numbers.

The output format of the audisp(1M), ipcs(1), ps(1), and top(1) commands will also change to make room for longer user and group ID numbers.

Impact

A file system conversion is needed for HFS and VxFS file systems to support large user and group IDs (that is, those that are above the old maximum of 59,999). For HFS file systems, this conversion happens automatically when the first reference to a large user or group ID is created on that file system. For VxFS file systems, this conversion happens as part of the process of upgrading to VxFS version 3 (using the vxupgrade(1M) command). HFS and VxFS conversion to support large user and group IDS is not reversible.

The following table summarizes the file system interoperability for large UIDs.

    ===================================================================

     File System Type          | Will it work on a | Will it work on a

                               | pre-10.20 system? | Large UID system?

    ===================================================================

     HFS with no large UIDs*   |       yes         |       yes

    -------------------------------------------------------------------

     HFS with large UIDs       |       no**        |       yes

    -------------------------------------------------------------------

     VxFS version 2            |       yes         |       yes***

    -------------------------------------------------------------------

     VxFS version 3            |       no          |       yes

    -------------------------------------------------------------------

     Third-party file system   |       yes         | changes by vendor

                               |                   | are required

    ===================================================================



        *  This is only for HFS file systems that never had large 

           UIDs.  HFS file systems that have at any time contained

           large UIDs are assumed to still contain large UIDs.

       **  Mounting will be prevented by software only on HP-UX 8.x and

           later.  

      ***  Large UIDs cannot own files.

Third-party file systems will be broken by the large UID changes to the vnode layer.

Scripts relying on the exact output format of the audisp(1M), ipcs(1), ps(1), or top(1) commands might not work. Scripts relying on exact field widths of the output of such commands are not, in general, supported.

Both the accounting file formats and the accounting commands are changing. This implies that the accounting commands cannot be used to examine accounting files generated on an earlier release of HP-UX.

Most applications will work as expected. However, there are some applications that might work incorrectly, unpredictably, or in a way that might introduce breaks in security. Only applications with the following might work unexpectedly:

The system has a large user or large group ID defined. (Systems that do not make use of a large user or group ID will not be affected.)
The application is compiled on a version of HP-UX that does not support large user IDs.
The application is made up of one or more of the following:
- Storage of user or group IDs in 16-bit (short) variables
- Output of a user or group ID into a field too narrow to hold the new maximum
- The getaccess(2) system call is used (this is an HP-proprietary extension)
- File access control lists (ACLs) are used (an HP-proprietary extension and the most likely source of breaks in security).

Again, all other applications should work as expected.

Mixed-mode NFS environments (that is, environments that contain some large UID-capable machines and some pre-large UID machines) will produce unexpected behavior, as described in the table below:

    ======================================================================

                           |  Will it work on a    |  Will it work on a

                           |  Small UID Client?    |  Large UID Client?

                           |  (HP or third-party)  |  (HP or third-party)  

    ======================================================================

     Small UID Server      |       yes             |    Patches needed*

     running HP-UX         |                       |

    ----------------------------------------------------------------------

     Small UID Server      |       yes             | Determined by server

     (third-party)         |                       | vendor

    ----------------------------------------------------------------------

     Large UID Server      |   Patches needed**    |       yes

     (HP or third-party)   |                       |

    ======================================================================



        *  Patches are needed because large UIDs cannot own files on the

           server.  Without patches to the server, large UID clients

           might introduce breaks in security in the server.

       **  The client sees the wrong owners for large UID-owned files.

           Without necessary patches to the client, small UID clients  

           will introduce breaks in security to large UID servers.

The patches needed for both the server and client are:

Release 9.0 -- PHKL_6758
Release 9.01 -- PHKL_6759
Releases 9.03, 9.05, and 9.07 -- PHKL_6760
Release 9.04 -- PHKL_6761
Release 10.0 -- PHKL_6762
Release 10.01 -- to determine availability, see the website http://us.external.hp.com/ and click on "Browse Patches".
Release 10.10 -- to determine availability, see the website http://us.external.hp.com/ and click on "Browse Patches".

The changes to libc needed for large user ID support will be made using intra-library versioning (not SysV versioning). So, applications compiled on a large user ID system will see the new behavior, while old applications will not. All HP-supplied libraries that are impacted by this versioning have themselves been versioned appropriately. However, third-party library suppliers might need to version their libraries to support both large and small user ID environments. Such versioning is needed if the library makes use of any of the constants listed above or any of these structure types:

struct acct
struct acl_entry_internal
struct audit_str_data
struct audit_str_hdr
struct inode
struct self_audit_rec

The getpwent(3C) functions will no longer translate out-of-range UID and GID values to (UID_MAX+1); the values will be returned as is.

Limitations

Although the full positive integer range can now be used for user IDs, system performance will suffer if large numbers of users or groups are defined on a single system.

HFS and VxFS file systems with quota checking enabled will maintain quota information only for users with user IDs less than 67,000,000. The edquota(1M) command will not permit quotas to be established for other users. This limitation will be removed in a future release.

Due to standards limitations, the cpio(1), ftio(1), pax(1), and tar(1) commands cannot support the full range of UID/GIDs. These commands will maintain the old UID/GID limits of 60,000. Any files that have more than 60K UID/GIDs will be archived with UID_NO_CHANGE/GUID_NO_CHANGE and will therefore be restored under the UID/GID of the restoring process.




	NOTE: `tar` searches for the archived user name in the `/etc/passwd` file and the group name in the `/etc/group` file and attempts to get the UID/GID from these files. If these are not found, `tar` attempts to establish ownership with the archived UID/GID. So, most files should be restored with the correct ownerships.

The fbackup(1M) tape format has been changed to accommodate the large UID/GIDs. The tapes created by this version of fbackup will be readable only by the matching version of frecover(1M) and not by older versions.

The dump(1M) tape format has also changed. If the file system being dumped has not contained large user or group IDs, dump will use the old tape format and will function as before. The archive created will be readable by older versions of restore(1M). However, when dumping a file system that has contained large user or group IDs, the new dump tape format will be used. The tapes created by this version of dump is readable only by the matching version of restore and not by older versions.

Performance

Performance is not degraded on identical system when large UID functionality is added. Some commands have performance that varies with the number of users and/or groups defined on a system; these commands can expect to have degraded performance on systems where many users or groups are defined.

The performance of the disk quota subsystem is dependent on the highest user ID value to which a quota has been assigned. Systems with quotas defined for large UIDs will see performance degradation.

Alternatives/Compatibility

Applications that do not work as expected, or applications expected not to work (as described above), can be fixed using the following steps:

Change any 16-bit (short) variables in which user or group IDs are stored into type uid_T or gid_t as appropriate. These types are defined in <sys/types.h>, <sys/unistd.h>, and so on).
Widen the output fields for user or group IDs to hold at least ten digits.
Recompile the application on a system that supports large user IDs.

Third-party file systems will need to recompile with the new kernel header files to adapt to the vnode layer changes.

Third-party libraries that need to be versioned should make use of the intra-library versioning facility to provide their existing behavior to old (pre-large-UIDs) applications and current behavior to current applications.

Obsolescence

New HFS file systems will be created in the small user ID format and will be automatically converted to large user ID format on demand as described above. By default, new VxFS file systems will be VxFS version 3, so they will support large user IDs. The future direction is the large user ID format; support for mounting or using file systems in the small user ID format will be removed in a future release.

Large User IDs

Technical documentation

» Table of Contents

» Index

Impact

Limitations

Performance

Alternatives/Compatibility

Obsolescence