> You'd have to be a privileged user to create such high uid user.

Or use a broken / misconfigured AD/LDAP to sync uid/gid across a pool of machines.

...which implies already having high privileges. (How do users with such high UIDs come into existence?)

>which implies already having high privileges. (How do users with such high UIDs come into existence?)

I am not so sure about that. I work at a smallish, place and by default my AD account has UID of 945004649. Still under the INT_MAX but not that far off. Our domain controller is running Windows 2012 R2, and nothing was changed or touched regarding UID's, everything was left at the default. We just create users and get whatever UID AD assigns.

This could happen anywhere. If you know that dynamically created users are in range {x} and AD/LDAP users are in range {y}, then a good sysadmin would choose a very high range for batch creations of specific types of accounts. This is fairly common practice. Modern Linux and Windows can support millions of UID's, so it is perfectly reasonable to say, "We are going to use range {y} for this project then nuke that entire range when we are done".

Active directory integration into Linux. Default numbers in the config files are very large.

Others pointed out that nobody was (uint16_t) -2, or 65534.

But, it turns out this value is, in fact, special in current day Linux as well. It's the default value of the special 'overflow' uid, can be seen/set at /proc/sys/fs/overflowuid.

Apart from some legacy stuff using 16-bit uid's, today it's mostly used for two things

1) In NFS, if mapping a user fails, then it gets assigned the overflowuid.

2) In containers with user namespaces, unmapped users again get the overflowuid.

For more details, see https://lwn.net/Articles/695478/

Very interesting, thanks.

Incorrect; nobody was 65534.

D'oh! I knew I'd get it wrong.

Thanks for the correction.

Was the special treatment of -1 intended by the developers, or did somebody mix up signed -1 with unsigned 65535?

In POSIX, many functions return -1 to indicate errors. So I guess the value (uid_t) -1 was reserved to avoid confusion. Also some functions (chown()) allow specifying (uid_t) -1 or (gid_) -1 to mark an omitted argument.

See https://en.wikipedia.org/wiki/User_identifier#Special_values

See above - it was -2 or 65534.

I think -2 is just easier to type and stands out more.

See https://superuser.com/a/706578/38062 .