What was the purpose of low-UID special user accounts like “bin”, “sys” or “daemon” in Unix?

Question

In a modern Linux system – modern enough to have upgraded useradd to a version from no earlier than February 2008 – it is usually the case that user accounts with UIDs no less than 1000 (other than the nobody user) represent human users, while those with UIDs in the range from 100 to 999 inclusive are dynamically allocated for system services running with reduced privileges.

But then there are some user accounts with UIDs lower than 100, as for example found in the default /etc/passwd file of Debian (and presumably its derivatives), in Fedora, and some even in OpenBSD such as bin, daemon, sys or uucp. Those account names are present as early as in V7 Unix:

root:VwL97VCAx1Qhs:0:1::/:
daemon:x:1:1::/:
sys::2:2::/usr/sys:
bin::3:3::/bin:
uucp::4:4::/usr/lib/uucp:/usr/lib/uucico
dmr::7:3::/usr/dmr:

Everyone knows what the root account is for, of course, and dmr is Dennis Ritchie’s personal account, but the purpose of the others seems much more obscure. What were they used for? Why would someone want to run processes under, or give file ownership to, user accounts like daemon or bin, as opposed to just using root? What other such special user accounts have appeared in historical Unices?

Answer 1

Debian includes a file which describes a number of historical accounts, with details covering more than Debian; it is shipped as /usr/share/doc/base-passwd/users-and-groups.txt.gz and its source can be viewed online.

Initially, root was the main “system” account and everything not owned by users was owned by root. This situation evolved over time to address a number of issues, the major one being that root can access anything on the system, without limitation — so a bug in a program running as root can cause widespread destruction.

daemon was intended to run daemons, acting as a non-root, non-human user. This ensured that daemons weren’t run as any given person on the system, and not run as root either, so that they couldn’t access files they weren’t supposed to. It turned out that it was desirable to separate daemons from each other too, which resulted in the still-current practice of per-daemon users. Early examples of the latter include uucp (as early as V7) and news; a slight variant of this idea is found in system groups which often provide shared access between human owners and daemons, e.g. mail, or between daemon producers and human readers, e.g. adm.

sys owned the kernel sources and related files such as header files; this allowed control of those files to be shared. A later variant of this was the src group, which owned /usr/src and was used to control write access to shared source code on the system.

bin was intended to own all non-suid binaries in the system. The purpose of this change wasn’t to limit what the binaries themselves could do, it was to limit what processes or administrators updating the binaries could do (yes, there are huge holes here; the focus here is limiting the consequences of accidents, not preventing malicious acts). bin owned all non-suid binaries and all directories containing such binaries, and therefore could install and update binaries, without being root and therefore without having access to users’ files.

A number of system users were traditionally found on systems with the purpose of allowing system manipulation from the console without being root; for example sync allowed any user at the console to flush pending writes.

uucp, like sync, has a non-shell program as its shell, and was how Unix-to-Unix Copy was implemented. The UUCP system on a local machine would log-in, usually via a serial connection, to a remote system as user uucp and speak its own protocol to the uucico program that would be run as the shell on the remote system. (For more on UUCP, see, for example, The Waite Group's Unix Communications and the Internet, published in 1995, which devotes 7 chapters to UUCP.) The uucp account was not only a way of logging in directly to run the uucico program but also had read+write access to the spool areas into and out of which files would be copied between two systems.

The Unix history repository contains a number of examples of /etc/passwd and /etc/group, which allow some of the history to be reconstructed — at least, releases by which certain accounts appeared. V5 already has daemon and bin; V6 separates bin into its own group (of which root is also a member); V7 has sys and uucp. (The accounts may of course have appeared earlier.)

Answer 2

What were they used for?

What other such special user accounts have appeared in historical Unices?

These accounts are often found on Unix and Unixoid systems. Except for root their UID numbers will differ between systems.

• root

  Well, UID0, what else :))

• bin

  Owns the executable files for (most) user commands. Essentially owning all files not owned by root or sys.

• daemon

  Owns and runs system server processes and their associated files. Guarantees that such processes run with the appropriate file access permissions.

According to the Linux Standard Base User & Group definition only these three are required users for Linux. All other are optional, but quite often found. Examples are:

• sys

  Sys user owns the default mounting point for the DFS cache, which must exist before any DFS usage. Including when /usr/sys is used to mount images.

• adm

  Owning all accounting services/files/directories. Also used by some diagnostic tools based on accounting data.

• nobody

  Originally devised by NFS, but soon also used for initializing databases and the like.

Some are tied to services / special products like

• uucp
• mail
• news

They are usually never used for login.

Some others do allow 'login', which directly results in a certain action.

• halt
• sync
• shutdown

Depending on Unix(oide) system, or Linux distribution, several more may exist. For example, a default Debian installation additionally creates

• games
• gopher
• ftp

Why would someone want to run processes under, or give file ownership to, user accounts like daemon or bin, as opposed to just using root?

The very same reason why different user accounts are created for users: to separate and encapsulate these applications. No-one wants to see mail crashing when installing a new NFS version. Or malicious programs break out of their user.

Running everything under root would open all gates to unwanted effects, and means giving up the very basic tools of access control. Never a great idea.

The reason numbers below 100 are used is an arbitrary historic relic from times when hard-coded privilege tests were still a thing.

Answer 3

In general, these non-human accounts exist for one of four reasons:

• To provide explicit deaggregated privilege separation for filesystem operations. bin is an example of this, it was the owner of all the non SUID binaries on the system, and anybody who was supposed to update those would login as that user (or switch to that user with su). The idea here is that it’s safer to log in as a non-privileged user than as the root user.
• To provide a simple form of remotely authorized triggering of system administration tasks. halt, shutdown, reboot, and sync are examples of this, you would log in as one of those users to directly trigger the associated action.
• As service accounts, either in the same sense as used today on modern Linux or Windows systems, or in a sense akin to how inetd works. news and mail are examples of the first case (both were used for whatever usenet and mail services were run on the system), while uucp fits the second case (‘traditional’ UUCP worked by the source system for a transfer logging in to the target system as the uucp user over a remote connection, and then talking to the uucico program that would be launched in place of a shell).
• As placeholders so that files or directories could still have an owner even when the only access control that was wanted was based on the group. sys and src both fit this, as did adm in some cases.

Note that the first two uses were only a thing because there was no equivalent to sudo or doas available at the time (sudo is about 8-10 years younger than UNIX, and doas is very recent comparatively, dating from 2015). Because there was no secure way to give access to specific commands or areas of the filesystem directly to trusted users without giving them root access, dedicated accounts were needed for such functionality.

The third use is still the case today, though normally on Linux the specific software being used has an associated user and group that share a name with it. The uucp style usage has largely fallen out of favor though.

Answer 4

Apart from security and segregating file management rights (e.g. after su - bin there is no risk that anything not belonging to "bin" will be damaged by rm -rf /) it is convenient when each file (for example in the /var or /var/tmp filesystem) has an origin indicator as part of its metadata rather than file name, which may be non-obvious or unreliable.

Using UID of file owners allows to perform partial cleanups of file systems, to identify runaway/buggy system processes, etc. in an automated way. Not so when all system activity takes place under root or a single non-root system UID.