[ 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
for.
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. The daemon user is also handy for locally
installed daemons, probably.
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 changelogs of base-passwd or base-files.
sys:
HELP: As with bin, except I don't even know what it was good for
historically.
I'm told that /dev/vcs* and /var/spool/cups are owned by
group sys, dunno why.
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/mana
lp:
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?
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.
uucp:
The uucp user and group is used by the UUCP subsystem. It owns
spool and configuration files. Users in the uucp group may run
uucico.
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, and squid runs as user proxy.
majordom:
Majordomo has a statically allocated uid on Debian systems for
historical reasons. It is not installed on new systems.
postgres:
Postgresql databases are owned by this user and group.
www-data:
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.
backup:
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:
Operator is historically (and practically) the only 'user' account
that can login remotely, and doesn't depend on NIS/NFS.
list:
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.
irc:
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
startup.
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:
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"
either..
HELP: What's the adm user good for?
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:
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.
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:
Full and direct access to serial ports. Members of this group can
reconfigure the modem, dial anywhere, etc.
dip:
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.
fax:
Allows members to use fax software to send / receive faxes.
voice:
Voicemail, useful for systems that use modems as answering
machines.
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:
Members of this group do not need to type their password when using
sudo. See /usr/share/doc/sudo/OPTIONS.
audio:
This group can be used locally to give a set of users access to an
audio device.
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:
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.
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
