I understand that unix user IDs (UIDs) are usually 16 or 32 bit unsigned integers but how can I find out for any given system (in a shell)?


You'll need to look in <limits.h> (or one of the files it includes, e.g., sys/syslimits.h on OS X) for the #define of UID_MAX.

Most recent operating systems (Solaris 2.x, OS X, BSD, Linux, HP-UX 11i, AIX 6) can handle up to two billion (2^31-2), so I would assume that and make a workaround for the more obscure systems that don't.

  • 1
    Unfortunately, there is no such thing as UID_MAX. For example, tools from shadow-utils use (uid_t)-1 to find out the max value for UID.
    – kirelagin
    Mar 30 '14 at 9:12
  • 5
    Most systems use /etc/login.defs which does have UID_MAX set for the highest usable UID value, 60000 on any system I've checked.
    – Ryaner
    Aug 5 '14 at 11:21
  • 6
    The manpage for login.defs indicates that in that context, UID_MAX only controls the highest uid that will automatically be assigned for new users created with useradd. Jan 26 '15 at 19:34
  • 2
    It's probably 2^32 (4 billion instead of 2). On RHEL UID 4,294,967,295 (2^32-1) is often reserved for an "invalid value" UID, and 4,294,967,294 (2^32-2) is reserved for the nfsnobody user in some operating systems. Thus the max non-reserved value is 4,294,967,293 (2^32-3)
    – tehnicaorg
    Sep 22 '18 at 22:06

glibc provides definitions for all those system types.

You can check /usr/include/bits/typesizes.h:

% grep UID_T /usr/include/bits/typesizes.h
#define __UID_T_TYPE            __U32_TYPE

Next you look into /usr/include/bits/types.h:

% grep '#define __U32_TYPE' /usr/include/bits/types.h
#define __U32_TYPE              unsigned int

This lets you find out the C type. Since you need the size in bytes, your best option is parsing the typedef name according to the specification in types.h:

We define __S<SIZE>_TYPE and __U<SIZE>_TYPE for the signed and unsigned
variants of each of the following integer types on this machine.

 16      -- "natural" 16-bit type (always short)
 32      -- "natural" 32-bit type (always int)
 64      -- "natural" 64-bit type (long or long long)
 LONG32      -- 32-bit type, traditionally long
 QUAD        -- 64-bit type, always long long
 WORD        -- natural type of __WORDSIZE bits (int or long)
 LONGWORD    -- type of __WORDSIZE bits, traditionally long

So, here is a one-liner:

% grep '#define __UID_T_TYPE' /usr/include/bits/typesizes.h | cut -f 3 | sed -r 's/__([US])([^_]*)_.*/\1 \2/'
U 32

Here U means unsigned (this can also be S for signed) and 32 is the size (look it up in the list above; I think, most of the time you can assume that that's already size in bytes, but if you want your script to be fully portable it might be better to do case switch on this value).

  • 1
    On my system (Ubuntu 12.04) and other Debian based systems the header file is: /usr/include/$(gcc -print-multiarch)/bits/typesizes.h or alternatively: /usr/include/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/bits/typesizes.h
    – pabouk
    Jul 7 '14 at 19:03
  • 1
    Having those glibc files would probably mean that there is a compiler available. So one could #include <sys/types.h> to have access to uid_t and print the result ( printf("uid_t: %d bytes (%d bits)\n", sizeof(uid_t), sizeof(uid_t) * 8); )
    – tehnicaorg
    Sep 22 '18 at 22:10

In this link the question is asked and a responder uses a trial & error method to determine the system in question uses a signed long int, leaving 31 bits to store the value, with a max of 2,147,483,647.

# groupadd -g 42949672950 testgrp
# more /etc/group

That's an interesting question. I'd be surprised if there was a standard, portable method to determine this.

I don't have a Linux box handy, but the id command on FreeBSD 8.0 wraps back to zero:

# id 4294967296
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)

I'm sure this is undefined behavior, but I'd wager that most versions of id would either wrap to zero with 65'536 (if 16-bit UID) and 4'294'967'296 or error out if you went beyond the system limit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.