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

Question

I am running an Ubuntu 12.04 desktop system. So far I have only installed some programs (I have sudo rights).

1. When I check the list of users on the system, I see a long list, like more than 20 users—when were these users created (e.g. daemon, sys, sync, games, pulse, etc.)? How are these related to new programs being installed?

2. If I run a program on my system, it should run with my UID. But on doing a ps, I see many other programs running with different UID (like root, daemon, avahi, syslog, colord etc.) — how were these programs started with different UIDs?

Solution 1

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.

Solution 2

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

Solution 3

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

• Jonathan de Boyne Pollard (2014). A side-by-side look at run scripts and service units.. Frequently Given Answers.
• Account Handling In Maintainer Scripts. Debian wiki.
• Packaging:UsersAndGroups. Fedora Project wiki.
• "Chapter 15. Users & Groups". Linux Standard Base Specification 2.1. 2004. Free Standards Group.
• "9.2 Users and groups". Debian Policy Manual. 2014-11-22. The Debian Policy Mailing List.
• "37.3. Standard Users". RHEL Deployment Guide. 11th Edition. 2013. Red Hat.
• Users and groups. Arch wiki.
• Carol Hurwitz and Scott McPeak (2001-02-12). Abolish Root Daemons!. DOI 10.1.1.120.3567.

Solution 4

On Linux when we install a service it creates a user of its service name or similar to that so that it can't access others files.

View more solutions

Comments

[Admin]

Think about it another way: when the computer first boots you're not logged in yet, and the programs have to run as somebody. They could all run as root, but that's insecure, as most of these programs are only responsible for a small part of the computer's operation. Once you're logged in, most programs you run directly will be run as you.

[Jake]

when I install a new program on ubuntu, does it create a new user ? If not, how come so many programs are running with different UID than mine ? I mean how are these programs run with diff UID ?

[toxefa]

You can run dpkg --get-selections | grep -v deinstall and compare it with your /etc/passwd file list of users if you like. As for your question: "...how are these programs run with diff UID", you can try this yourself. Write a random bash script test_file that contains something innocuous (echo "Test"). Then sudo chmod 755 test_file (so it's readable and executable by anyone and readable, writeable and executable by the owner) then sudo chown nobody which will assign it to the user nobody. Then run it. The 'program' test_file just ran with the UID nobody.

[Jakob Bennemann]

This is a convention, but not at all required and certainly not universal. In fact, it's really not that common anymore…

[Gilles 'SO- stop being evil']

@HalosGhost Uh? No, it's a very common convention, still going strong. This answer is incomplete but perfectly correct.

[Jakob Bennemann]

@Gilles, I didn't say (or even imply) that it was incorrect. But it is mostly out of date. A huge portion of services these days (with the advent of systemd) are just service files. Now that's not to say that per-service user accounts don't exist anymore; they definitely do. But, for example, there are only 24 accounts on my whole system where I have plenty more services.

[Scorion.Poison]

@py4on Not quite... it ran from a file with the nobody UID, but it ran with your UID; you'd need to make it a SUID file to do that, but the SUID bit is dropped if the file is ran with an interpreter.

[toxefa]

Ok as I can't edit my comment above but the dpkg bit is still useful (hopefully) please disregard the part about running it as yourself! Either go with SUID or login as a different user for this to make sense

[lonix]

@Gilles I have the same situation as HalosGhost - more services than accounts. So does that mean that they all run as root?