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.
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.
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.
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/group, which allow some of the history to be reconstructed — at least, releases by which certain accounts appeared. V5 already has
bin; V6 separates
bin into its own group (of which
root is also a member); V7 has
uucp. (The accounts may of course have appeared earlier.)