When were these users created?
In the cases of the ones that you mentioned, they were created at system installation. These user accounts are conventional, some dating back decades. They are also standardized. The Linux Standard Base divides them into:
- the required standard user accounts,
root
, bin
, and daemon
; and
- the optional standard user accounts
adm
, lp
, sync
, shutdown
, halt
, mail
, news
, uucp
, operator
, man
, and nobody
Other user accounts that are mentioned here — pulse
, avahi
, colord
, and Debian-exim
(to pick one from py4on's password file) — bring us to your next question.
How are these related to new programs being installed?
The non-standard user accounts are created, and destroyed, by the "maintainer scripts" for various packages, as those packages are installed and purged. A user account will be created by the package's so-called postinst
maintainer script, which runs getent
to see whether the user account already exists, and useradd
if it does not. In theory it would be deleted by the package's so-called postrm
maintainer script, running userdel
.
In practice, user accounts for packages aren't deleted. The Fedora wiki (q.v.) explains that this would be fraught with difficulty. See Debian bug #646175 for an example of this rationale in action, where it is decided simply not to delete the rabbitmq
user account when the package is purged, to solve a problem with a dæmon that continues running under the aegis of that account.
How were these programs started with different UIDs?
Under Unix and Linux, a process running under the aegis of the superuser can change its user account to something else and continue running the same program, but the reverse is not permitted. (One must use the set-UID mechanism.)
The dæmon management system runs as the superuser. Its configuration data specify that particular dæmons run under the aegises of particular user accounts:
- With System 5
rc
the script in /etc/init.d
uses a helper tool such as start-stop-daemon
and its --chuid
option.
- With a daemontools family service manager, the
run
script calls setuidgid
, s6-setuidgid
, chpst
, or runuid
with the user account name. There are examples of this in https://unix.stackexchange.com/a/179798/5132 that set the nagios
user account.
- With upstart there's a
setuid
stanza in a job file, that specifies the user account. This is not particularly fine grained, and sometimes one wants what is described at https://superuser.com/a/723333/38062 .
- With systemd there's a
User=
setting in the service unit file, that specifies the user account.
When the dæmon management system spawns a process to be the dæmon, these mechanisms drop superuser privileges so that the dæmon process continues to run under the aegis of the unprivileged user account.
There's a fairly lengthy explanation why good dæmon management is done this way. But you didn't ask why; only when, how, and whence. ☺ A very brief précis, therefore:
Unix and Linux operating systems insulate processes running under the aegises of different user accounts from one another. Historically, if one was able to take over a dæmon that ran as the superuser, one could do anything that one liked. A dæmon that runs under the aegis of an unprivileged account, on the other hand, can only access files, directories, devices, and processes that that unprivileged account can. A system of mutually untrusting dæmon programs all running under the aegises of different user accounts and unable to access/control one another's (internal, trusted) files/directories/processes/devices, therefore, is that much harder to crack.
Further reading