Debian has always lacked an explanation of what the various users and groups are for. Such a document is useful for sysadmins who must determine the correct way to use various users and groups. It's useful for developers as well, and it might help us find unused users and groups, or find unstated requirements about use of users and groups that could be put in policy.
So here's a start. There are a lot of unanswered questions; can you help me answer some of them? ------------------------------------------------------------------------------ Many users have a corresponding group, and these pairs will be treated together: root: Root is (typically) the superuser. daemon: Some unprivileged daemons that need to be able to write to some files on disk run as daemon.daemon (portmap, atd, probably others). Daemons that don't need to own any files can run as nobody.nogroup instead, and more complex or security conscious daemons run as dedicated users. bin: HELP: No files on my system are owned by user or group bin. What good are they? Historically they were probably the owners of binaries in /bin? It is not mentioned in the FHS, debian policy, or the changelog of base-passwd or base-files. sys: HELP: As with bin, except I don't even know what it was good for historically. sync: The shell of user sync is /bin/sync. Thus, if its password is set to something easy to guess (such as ""), anyone can sync the system at the console even if they have no account on the system. HELP: If that is the only purpose of user sync, then group sync seems not very useful. The sync user could just as well be in nogroup. games: Many games are sgid to games so they can write their high score files. This is explained in policy. HELP: My system has no files owned by user games, and I don't see the point of the user, aside from symmetry. man: The man program (sometimes) runs as user man, so it can write cat pages to /var/cache/man HELP: My system has no files owned by user man, and I don't see the point of the user, aside from symmetry. lp: HELP: I assume it's used by lpr, as I have not owned a printer in years and have not used lpr in longer, I can't say what exactly the user is used for or what the group is used for. Or is the idea to make the printer device owned by one or the other, to let eg, users in group lp cat files to it directly? mail: Mailboxes in /var/mail are owned by group mail, as is explained in policy. The user and group is used for other purposes as well by various MTA's. news: Various news servers and other associated programs (such as suck) use user and group news in various ways. Files in the news spool are often owned by user and group news. Programs such as inews that can be used to post news are typically sgid news. HELP: I notice that /etc/news/leafnode/config and even /etc/news are here owned by news.news. Which is odd, because those arn't things the programs should be editing on the fly. What gives? uucp: HELP: Presumably used for UUCP, which I know nothing of. HELP: Why is minicom owned by group uucp? Is this a bug? proxy: Like daemon, this user and group is used by some daemons (specifically, proxy daemons) that don't have dedicated user id's and that need to own files. For example, group proxy is used by pdnsd. HELP: What uses user proxy? majordom: Majordomo has a statically allocated uid on Debian systems for historical reasons. HELP: Do we still even ship that buggy old POS? And can someone remember what the hysterical raisins were? postgres: HELP: Presumably used by the postgresql database? www-data: HELP: Er, I should know this, but this box doesn't run apache and I'm offline. backup: HELP: ? operator: HELP: No files owned by it here, what's it good for? list: HELP: Evidently used by smartlist? irc: HELP: Why does an irc daemon need its own static user and group? gnats: HELP: Evidently used by gnats. And it needs a static set why? nobody, nogroup: Daemons that need not own any files run as user nobody and group nogroup. Thus, no files on a system should be owned by this user or group. Other groups have no associated user: adm: HELP: On my system, use of group adm is confined entirely to /var/log, and I've never seen the point. Oh, and /dev/xconsole is owned by group adm, but that may be a (local?) bogosity. tty: Tty devices are owned by this group. This is used by write and wall to enable them to write to other people's tty's. disk: HELP: Well, I have some disk devices in /dev/ owned by the group, but I can't see the point. On another system, I noticed that some of the files lilo puts in /boot/ are also owned by disk. I can imagine local uses for such a group, like if you want to give some users in the group direct access to some hard disk. But these uses I've found on my systems seem to preclude doing that easily; if I put a user in group disk here, they'd have write access to the root filesystem. kmem: /dev/kmem and similar files are readably by this group. This is mostly a BSD relic, but any programs that need direct read access to the system's memory can thus be made sgid kmem. dialout: HELP: Is this used for /dev/cua devices or something? fax: HELP: ? voice: HELP: ? cdrom: This group can be used locally to give a set of users access to a cdrom drive. floppy: This group can be used locally to give a set of users access to a floppy drive. tape: This group can be used locally to give a set of users access to a tape drive. sudo: HELP: Nothing uses it here, and I have sudo installed.. Maybe there's a way to only let users in this group use sudo? audio: This group can be used locally to give a set of users access to an audio device. dip: HELP: WHat did this group's name signify? DIaluP? pppd may only be run by users in the dip group (and by root of course). src: This group owns source code, including files in /usr/src. It can be used locally to give a user the ability to manage system source code. HELP: /usr/src is owned by group src and is setuid. This doesn't make files put there by foo-src packages necessarily be owned by group src though. If the intent is to make group src be able to manage source code, perhaps policy should say that foo-src packages make files in /usr/src owned and writable by the group (and files in tarballs dropped there likewise?) shadow: /etc/shadow is readable by this group. Some programs that need to be able to access the file are set gid shadow. utmp: This group can write to /var/run/utmp and similar files. Programs that need to be able to write to it are sgid utmp. video: This group can be used locally to give a set of users access to an video device. staff: HELP: So, /usr/local and /var/local are owned by it, but how's it differ from say, adm, and what's the historical meaning, and the current purpose? users: While Debian systems use the user group system by default (each user has their own group), some prefer to use a more traditional group system. In that system, each user is a member of the 'users' group. -- see shy jo