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
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
Reply to: