Re: Bug#484841: staff group root equivalence
Don Armstrong writes ("Re: Bug#484841: staff group root equivalence"):
> Yeah, but by default, if you have staff access, you can easily gain
> root access, so there's really no distinction between the two. [In
> Debian, this could be done by shoving in a special /usr/local/bin/awk
> to trap cron.daily/standard calling it as root, for example.]
Since I perpetrated this I should explain it.
It is useful to have a group which is able to write to /usr/local.
This allows people who have _in principle_ root access to avoid
accidents.
A user who is in group staff can avoid becoming root to edit things in
/usr/local, thus limiting the damage they can do by mistake. One big
example for this is `make install'. If there is some set of process
properties which have write access to /usr/local but not to /, then
`make install' is much safer - it can't accidentally drop stuff all
over the rest of the filesystem. Of course you're still exposed to
malice, but `sudo make install' is not really advisable even if you
know the source tree not to be malicious - after all it might be buggy
or the author might have different ideas where to put things.
On my own systems I typically run much of the time using an account
which has passwordless access to root, just by saying `really' (really
is a bit like sudo only simpler and less broken). I put myself in the
staff group and that means I can mess about in /usr/local without
having to specially don a root hat (eg, `really emacs'). This helps
avoid accidents.
(Note that even with passworded sudo, subversion of an account which
can `sudo bash' can become equivalent to root the next time the real
human types the password.)
Obviously the best answer to how to provide some set of processes
(including all the processes of certain users) with the ability to
write to /usr/local is to make /usr/local owned by some group and mode
g+rw (directories g+rwsx).
Perhaps the choice of the name `staff' for this group was a mistake.
It's a cultural convention that I had picked up on a couple of UNIX
systems I had acquired over the preceding years, but of course other
people may have different conventions. So I don't object to the idea
that the group should be renamed.
Also since an administrator who wants this setup can easily institute
it by hand, with a group of their choice, I don't mind if the default
install is changed. BUT:
What _is_ important is that the existing installations aren't broken,
for example by new packages creating directories with the wrong
permissions. With the current arrangements this is difficult to do
with a different group name: packages are expected to contain
directories which are group-owned by `staff', so there is not really
much facility for local configuration.
So I would suggest that documenting the situation would probably be
best. After all anyone who puts users in a system group ought to have
some care about what they're granting access to.
If change is felt to be essential then I think the only option is to
require packages to create directories in /usr/local with
`mkdir -p -m2755' (or something like it). If we do that then those
directories will naturally inherit the permissions from their parents,
so that the local configuration will be sticky.
Ian.
Reply to: