On Wed, Mar 16, 2005 at 06:00:14PM +0100, Santiago Vila wrote: >On Wed, 16 Mar 2005, Brendan O'Dea wrote: >> Having /usr/local staff writable is *very* useful when using CPAN to >> install local packages w/- having to do the "make install" as root. >> >> This is a benefit I'd prefer not to see removed, since the alternative >> generally involves giving sudo access to a subset of users... which is >> in my experience tantamount to simply adding more entry points to >> gaining uid=0*, worse IMHO than having a subset of the filesystem >> writable to that same set of users. > >That's not really the alternative. The alternative is doing it yourself >(i.e. chgrp -R staff /usr/local and so on) instead of it being the default. > >This proposal is not to prevent people from having /usr/local group-writable >by staff, it's just a proposal to have "neutral permissions" in /usr/local.
Fair point, although while /usr/local is staff-writable by default, no users are in group staff by default. So out of the box, this situation is no different to having the group as root. The only difference is to users who *do* wish to take advantage of this facility, saving the need for: # chgrp -R staff /usr/local /var/local # chmod -R +t,g+w /usr/local /var/local and requiring only the final step of: # adduser fred staff >Should we count your mail as a formal objection? You know, it only >takes a negative vote to reject a policy proposal, even if it's >supported by a lot of people. I think this is going to be a real pity. A formal objection? I was of the belief that this was still being discussed. While there has been some support, there is not consensus: both myself and Bill Allombert have raised issues with the proposal as given in message <[EMAIL PROTECTED]> of changing the group of /usr/local to root. I believe that the facility of having a group which may write to /usr/local is very useful and should be retained. Furthermore, I would assert that the current situation poses no security risks without the administrator choosing to add users to the staff group. The group need not be called "staff" specifically, since due to the generic nature of the name it is possible that an administrator may choose to add staff users to that group (either for documentary purposes, or to provide write permission to some other, site-specific part of the hierarchy) without being aware that this would allow them to write to elements of root's PATH. Using "local" for /usr/local (in line with the current "src" for /usr/src) may be an option if the above was deemed to be a sufficient risk. Clearly documenting the possible risks of adding a user to the group should probably be added to users-and-groups.txt . Having /home writable by group staff OTOH doesn't seem particularly useful. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
