19

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?

4
  • 2
    The purposes of some of them I actually know already (like toor, bin, sync and halt), but I don’t remember the sources where I learned those any more, and I have a hard time finding a comprehensive resource that would explain some others, like uucp or sys. Jul 29 at 19:35
  • 2
    Those are for daemons that do not belong to a specific real user, and do not require root powers, so you need a pseudo user and these were typically picked out of a hat. Packages and the standardization happened much much later. Jul 30 at 15:48
  • uucp has the same purpose as an account like ntp or ldap.
    – Mark
    Jul 30 at 22:13
  • It amuses me to think every V7 installation comes with an account for Dennis Ritchie to gain access by default.
    – OrangeDog
    Aug 1 at 19:49

4 Answers 4

34

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.)

2
10

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.

6
  • This seems to fall short of explaining why would someone want to use a separate user account for those purposes. And since I am in no rush to see an answer, I would have appreciated something more thoroughly researched, that bothers to cite its sources, instead of a lazy FGITW rep grab. Jul 29 at 20:06
  • 6
    If you're not in a rush, then simply don't check right away :)) Beside, an answer is a gift by a stranger his time to help. It might be appropriate to show basic decency to spare arrogant complains and baseless accusations. Looking close, yo may notice that I neither need, nor care to pile up rep. Beside that, FGITW is not only outdated due the revised sorting algo, it's as well a complete useless strategy. In the long run only valuable answers count :)) Quality always outruns hate.
    – Raffzahn
    Jul 29 at 20:28
  • 13
    @user3840170 and Raffzahn, I'd rather if you tried especially hard to be nice to each other.
    – wizzwizz4
    Jul 29 at 20:38
  • 1
    "gopher", now, that's a name I haven't heard in a long time... A long time. Jul 30 at 15:49
  • Ideally there should be no files owned by nobody, so a process running under this account would have the least access.
    – Barmar
    Jul 30 at 15:51
7

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.

5
  • The sudo history is a nice part of this answer.
    – davidbak
    Jul 30 at 17:25
  • Another possible motivation for halt/reboot/shutdown is so that those actions could be logged by the existing mechanisms for logging user logins, like wtmp. Modern wtmp likewise records them as if they were logins by users named shutdown or reboot, whether or not those users actually exist. Jul 30 at 17:26
  • Not to mention having these actions as user accounts allows invoking them directly from /bin/login, without even logging in to a proper account first. These days, a graphical login greeter would just have a separate button for shutting down or rebooting, but back when text-based terminals were king… Jul 30 at 18:48
  • 1
    @user3840170 I’ve seen them used with plain XDM graphical greeters too! Jul 31 at 6:54
  • I wonder though, why bother with ‘placeholder’ users? These days it is common to have e.g. device nodes owned by root:tty or similar, with the UID and GID entirely disparate. Jul 31 at 7:15
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.