On Wed, 16 Mar 2005, Brendan O'Dea wrote: > On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote: > >In this report, the submitter complains about /usr/local/bin being in > >the PATH by default at the same time directories under /usr/local are > >root:staff and world-writable. His complain is based on the existence > >of become-any-group-but-root bugs. > > Not world-writable. Writable by group staff. > > >If this is a bug at all, I think we should probably drop the root:staff > >thing instead of changing the default PATH. So: Would anyone here > >second the following patch, if it were a policy proposal? > > 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. If you are a perl hacker and like /usr/local to be group writable, you will always be able to change the permissions yourself. The same is true, of course, about putting /usr/local/bin in the PATH. The difference is that you don't need to be a perl hacker to consider /usr/local/bin in the PATH a useful thing (not to mention we already have a lot of perl modules available via "apt-get install"). I bet that most people would add /usr/local/bin to the PATH if it weren't the default, for private shell scripts, perl scripts, python scripts, or whatever. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
