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

Re: exploring debian's users and groups

[ Please honor Reply-To, y'all. ]

Wichert Akkerman wrote:
> Amusingly enough Jochen Voss made a draft of such a document recently
> that is still sitting in my mailbox. I'll flesh it out and add it to
> base-passwd later today.

Looking forward to seeing it. Here is what I've come up with merging
what people had to say in this thread. There are still quite a few
HELP's, most notably nobody seems to have a clue what bin and sys are

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. The daemon user is also handy for locally
	installed daemons, probably.


	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 changelogs of base-passwd or base-files.


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

              I'm told that /dev/vcs* and /var/spool/cups are owned by
	      group sys, dunno why.


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


	Used by printer daemons.

	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.


	The uucp user and group is used by the UUCP subsystem. It owns
	spool and configuration files. Users in the uucp group may run


	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, and squid runs as user proxy.


	Majordomo has a statically allocated uid on Debian systems for
	historical reasons. It is not installed on new systems.


	Postgresql databases are owned by this user and group.


	Some web browsers run as www-data. Web content should *not* be
	owned by this user, or a compromised web server would be able to
	rewrite a web site. Data written out by web servers, including
	log files, will be owned by www-data.


	Presumably so backup/restore responsibilities can be locally 
	delegated to someone without full root permissions?

	HELP: Is that right? Amanda reportedly uses this, details?


	Operator is historically (and practically) the only 'user' account
	that can login remotely, and doesn't depend on NIS/NFS.


	Mailing list archives and data are owned by this user and group.
	Some mailing list programs may run as this user as well.
	HELP: Why is the user name "SmartList" when this appears to have a
	      more general useage, including by mailman.


	Used by irc daemons. A statically allocated user is needed only
	because of a bug in ircd -- it setuid()s itself to a given UID on


	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:


	Group adm is used for system monitoring tasks. Members of this
	group can read many log files in /var/log, and can use xconsole.

	Historically, /var/log was /usr/adm (and later /var/adm), thus the
	name of the group.

	HELP: Perhaps policy should state the purpose of this group so
	      users may be safely added to it, in certanty that all they'll
	      be able to do is read logs. Wouldn't hurt to rename it "log"
	HELP: What's the adm user good for?


	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.


	Raw access to disks. Mostly equivilant to root access.

	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.


	Full and direct access to serial ports. Members of this group can
	reconfigure the modem, dial anywhere, etc.


	THe group's man stands for "Dialup IP". Being in group dip allows
	you to use a tool such as ppp or dip to dial up a connection.


	Allows members to use fax software to send / receive faxes.


	Voicemail, useful for systems that use modems as answering


	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.


	Members of this group do not need to type their password when using
	sudo. See /usr/share/doc/sudo/OPTIONS.


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


	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.


	Allows users to add local modifications to the system (/usr/local,
	/home) without needing root priveledges. Compare with group "adm",
	which is more related to monitoring/security.


	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: