Bug#538392: group staff: moving forward

["Thijs Kinkhorst" <thijs@debian.org>]

On Tue, August 11, 2009 22:53, Russ Allbery wrote:
> Thijs Kinkhorst <thijs@debian.org> writes:
>
>
>> The TC has decided on the following resolution for the group staff
>> issue:
>>
>>
>>> | 2. Decide to change the default so that /usr/local is not writeable
>>> by | group staff anymore. This change should only be implemented after
>>> an | appropriate transition plan exists which enables system
>>> administrators | to maintain the ability of group staff to write to
>>> /usr/local.
>>> | (Reasons for the change are the adaption of other tools like sudo on
>>>  | most sites, and the concept of "least surprise" for novice users.)
>>>
>>
>> I'd like to move forward with this bug so that it can be resolved for
>> squeeze.
>>
>> The TC decided an "appropriate transition plan" should exist. If we
>> would change the default on a new system to root:root 2775 for
>> /usr/local, a sysadmin needs to chgrp that to staff once to regain the
>> old behaviour.
>
> Changing the magic group from staff to root does not address the problem
> that was raised before the TC so far as I can see.  The TC decision as I
> understood it requires that the default mode be 2755.  The staff group
> was already empty by default, so swapping it out with another
> empty-by-default group but keeping the directories as group-writable is
> entirely equivalent to the current situation.

I'm not sure it's entirely equivalent, as the directory in the new
situation would be owned by group 0 / root. This is clearly a special
group just as user root is a special user; much more clearly than staff
would be. I believe that the problems that could occur with the original
situation relate to non-root users being in group staff one way or the
other, and then elevate that to root. What would be a realistic scenario
where the group 'root' contains users that aren't supposed to be root?

> The transition plan work entails determining how to set the mode of newly
>  created directories based on the local system administrator preference,
> I think.

I'm fine either way, and will work on that if desired, but of course I'd
like to keep things as simple as possible.


cheers,
Thijs