Why are there many accounts? I'm the only user

User accounts are used not only for actual, human users, but also to run system services and sometimes as owners of system files. This is done because the separation between human users' resources (processes, files, etc.) and the separation between system services' resources requires the same mechanisms under the hood.

The programs that you run normally run with your user ID. It's only system daemons that run under their own account. Either the configuration file that indicates when to run the daemon also indicates what user should run it, or the daemon switches to an unprivileged account after starting. Some daemons require full administrative privileges, so they run under the root account. Many daemons only need access to a specific hardware device or to specific files, so they run under a dedicated user account. This is done for security: that way, even if there's a bug or misconfiguration in one of these services, it can't lead to a full system attack, because the attacker will be limited to what this service can do and won't be able to overwrite files, spy on processes, etc.

Under Ubuntu, user IDs in the range 0–99 are created at system installation. 0 is root; many of the ones in the range 1–99 exist only for historical reasons and are only kept for backward compatibility with some local installations that use them (a few extra entries don't hurt). User IDs in the range 100–999 are created and removed dynamically when services that need a dedicated user ID are installed or removed. The range from 1000 onwards is for human users or any other account created by the system administrator. The same goes for groups.

I presume you're finding this list of users by checking /etc/passwd? This is totally normal - 'users' serve to carry a set of permissions, useful for locking down not just 'actual users' but also programs to certain areas of your system and tracking what they changed (same concept with groups).

I've inserted one of my Raspberry Pi /etc/passwd files below for your reference; you'll notice the user ntop at the bottom of this file, created by the program ntop (network monitoring). Similarly sshd, gnats bug reporting etc.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
pi:x:1000:1000:,,,:/home/pi:/bin/bash
sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin
ntp:x:102:104::/home/ntp:/bin/false
statd:x:103:65534::/var/lib/nfs:/bin/false
messagebus:x:104:106::/var/run/dbus:/bin/false
usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false
lightdm:x:106:109:Light Display Manager:/var/lib/lightdm:/bin/false
smmta:x:107:110:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:108:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
Debian-exim:x:109:113::/var/spool/exim4:/bin/false
ntop:x:110:115::/var/lib/ntop:/bin/false

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.

Why are there many accounts? I'm the only user

Further reading

Tags:

Process

Software Installation

Users

Accounts

Related

Recent Posts