How essential are usernames ( compared to uids )?

Question

Background: I recently read about a freedesktop.org-bug which allowed executing any systemctl command for uid > INT_MAX. Thus I ran:

root@host$> useradd -u 4000000000 largeuiduser
root@host$> su largeuiduser
largeuiduser@host$> systemctl ["whatever"]
[bug exists, and "whatever" gets executed]
largeuiduser@host$> exit
root@host$> userdel largeuiduser

Looking for a cleaner way I later found

root@host$> setpriv --reuid 4000000000 systemctl ["whatever"]
[bug exists, and "whatever" stuff gets executed]

Showing that for exploiting the bug, there is no need for a (temporary) username. It also made apparent, that I was not quite sure about: how essential usernames actually are ?.

Question My question hence is. How dispensible are usernames, from the kernel (linux/posix) perspective? Are they needed, can they be used?

The suspicion of mine is, that the username is only a sort of "amenity" used exclusively in userspace.

A good answer would attempt to shed some light on this, by providing information of in what settings usernames become "necessary", and in which setting they are "expendable".

For an exercise about how it works in practice without user names, you can look at the most used unix system of all times: android. On android, all user names (with some exceptions: root, radio, system, shell, etc) are mapped to uids by a simple formula (uid `10000` is the same as `u0_a0`, `u000_a000`, etc). Most user ids do match installed apps, but the std library functions don't know anything about them. — , Dec 05 '18 at 21:00

score 6 · Accepted Answer · answered Dec 05 '18 at 19:38

In the Linux and BSD worlds, the kernel operates almost wholly in terms of numeric user and group IDs. There is a standardized C library that provides access to a user database, where names can be looked up from IDs and vice versa, which is how applications softwares get from names supplied by humans to the IDs needed in system calls, and back again. Process credentials and access control list entries all operate in terms of the IDs.

The one exception is the (not standardized) setlogin() API function in the BSD world, which operates in terms of a string, a user name, rather than in terms of a numeric user ID. The kernel places no interpretation upon this string, however.

One could write applications programs that operated entirely in terms of the numeric IDs, presenting those to human beings. But that is not the way that most softwares are written, for the simple reason that human beings work better with accounts that are named.

The kernel also has no notion of non-existent accounts. All IDs (aside from a few reserved values) are valid as far as the kernel is concerned. You could (as the superuser) start a process running as UID 24394, and create filesystem objects owned by that UID (in places where it has permission to, of course), and the kernel would not complain.

The PolicyKit bug is not really about UIDs, note. It is about a program named pkttyagent abending …

ERROR:pkttyagent.c:156:main: assertion failed: (polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)

… and the authorization mechanism failing open rather than failing closed in such circumstances, returning that the user is authorized across the Desktop Bus.

How essential are usernames ( compared to uids )?

1 Answers1

Further reading