Re: exploring debian's users and groups
On Tue, Aug 07, 2001 at 01:31:38PM -0400, Joey Hess wrote:
> 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.
I'm thrilled to see that a developer has taken up this chore. I
have some comments, but first a meta-question: where will this
document end up? When the matter has been discussed in the past, I
recall some resistance to putting it in policy. But the document
can only be helpful for users if developers observe it scrupulously,
and it is hard for me to see that happening without it being policy.
In a similar vein, many of my comments are suggestions that you add
some specific guidelines for packagers, to supplement the general
descriptions. The descriptions are educational, but without more
details they may not be especially useful. However, I understand
this may be outside the scope of what you set out to do.
One more overall point: It would be nice to see explicit
information about which users/groups are practically useful to the
average admin, and which are implementation details. In particular,
to which groups is it normally appropriate to add users, and which
users/groups should be given ownership of files?
> 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.
Is this a legacy user/group, or can new programs use it? What is
the point of the group--couldn't the programs be daemon.nogroup?
What rationale is there for using daemon versus an app-specific
user/group?
I would suggest that app-specific users (along with group nogroup)
be recommended in most cases, and that daemon, nobody, and nogroup
be deprecated for Debian programs.
> bin:
>
> HELP: No files on my system are owned by user or group bin. What
> good are they?
Is there any prospect of getting rid of the "mystery" users/groups?
> 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.
This, along with some others, is clearly a matter of local policy.
I would hope we could remove it from stock Debian (eventually).
> 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.
Groups like this are pointless--they acknowledge the desire for
compartmentalization, but compartmentalize along arbitrary
boundaries. They should be deprecated.
> 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.
Several logs can't be read by adm, and several are world-readable,
but this seems to be arbitrary (because there is no policy). A
simple policy would be: Programs that have sufficient permissions
should write logs as root:adm 0640. Of course, most programs should
prefer to log via syslog.
Should the setgid bit be used in /var/log to allow non-privileged
daemons to get log permissions right?
> disk:
For all the /dev groups, it is important both to document how the
admin can use them, and to ensure that they don't give away extra
privilege not documented. The second is probably hard on some
cases, but perhaps a config tool could help.
> 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?)
Yes.
> staff:
local policy.
Andrew
Reply to: