On Tue, August 11, 2009 22:53, Russ Allbery wrote: > Thijs Kinkhorst <th...@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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org