[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

exploring debian's users and groups

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


	Root is (typically) the superuser.


	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.


	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.


	HELP: As with bin, except I don't even know what it was good for


	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


	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.


	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.


	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?


	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.


	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


	HELP: Presumably used for UUCP, which I know nothing of.

	HELP: Why is minicom owned by group uucp? Is this a bug?


	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

	HELP: What uses user proxy?


	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?


	HELP: Presumably used by the postgresql database?


	HELP: Er, I should know this, but this box doesn't run apache and
	      I'm offline.


	HELP: ?


	HELP: No files owned by it here, what's it good for?


	HELP: Evidently used by smartlist?


	HELP: Why does an irc daemon need its own static user and group?


	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

Other groups have no associated user:


	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 devices are owned by this group. This is used by write and wall
	to enable them to write to other people's tty's.


	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.

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


	HELP: Is this used for /dev/cua devices or something?


	HELP: ?

	HELP: ?


	This group can be used locally to give a set of users access to a
	cdrom drive.


	This group can be used locally to give a set of users access to a
	floppy drive.


	This group can be used locally to give a set of users access to a
	tape drive.


	HELP: Nothing uses it here, and I have sudo installed.. Maybe
	      there's a way to only let users in this group use sudo?


	This group can be used locally to give a set of users access to an
	audio device.


	HELP: WHat did this group's name signify? DIaluP?

	pppd may only be run by users in the dip group (and by root of


	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

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


	/etc/shadow is readable by this group. Some programs that need to
	be able to access the file are set gid shadow.


	This group can write to /var/run/utmp and similar files. Programs
	that need to be able to write to it are sgid utmp.


        This group can be used locally to give a set of users access to an
	video device.


	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?


	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'

see shy jo

Reply to: