Re: Bug#484841: staff group root equivalence
* Don Armstrong (don@debian.org) [090302 22:16]:
> On Mon, 02 Mar 2009, Manoj Srivastava wrote:
> > This way, each research group had special privileges to their
> > machines, but not any others, and the IT folks still had control.
> >
> > Similar things were done at some of the larger companies I worked
> > for; so there is a use case. (And I think UNIX machines back in the
> > 80's and early 90's came set up that way by default; I know Ultrix
> > and OSF/1 did).
>
> It seems to me that most of these cases would be dealt with using sudo
> now, as it would enable you to restrict the users to having root
> access on a specific machine, since being in staff means being able to
> trivially get root on that machine at any time.
I would like to get on with this bug report.
To me, the situation looks as follows: Having write-access for group
staff to /usr/local was a resonable decision when it was decided
first. However, since then time went by, and it looks like most
reasonable use cases disappeared. I agree with the principle of least
surprise, and so I think we should change that behaviour.
Ian said that we should require packages to create directories in
/usr/local with mode 2755, so that permissions will be inherited.
I agree that we should try to make it possible for users to keep a
special group.
However, I'm not sure if that's the best way to achieve it - I didn't
try out but I'd assume that any directory in a deb won't get the group
inherited from the parent directory. I think that a Post-Invoke-action
in apt.conf would be the better way. (We should probably document that
somewhere how to achive it.)
Anyways, I think we should do the basic decision whether we want to
/usr/local to be writeable by staff or not soon, and then try how to
best do a transition.
cheers,
Andi
Reply to: