On Fri, Mar 11, 2005 at 06:27:24PM +0100, Santiago Vila wrote: > On Fri, 11 Mar 2005, Bill Allombert 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. > > > > Is there evidence of such bugs ? There is no binaries sgid staff in > > Debian to start with. > > You don't need sgid staff binaries. Quoting the submitter: > > Become-any-user-but-root and become-any-group-but-root bugs are quite > common. When a group of machines share user home directories via NFS > exported from somewhere with default root-squash, getting root on one > machine gives precisely that on all others of the group. There have been > "genuine" such bugs also e.g. in sendmail [6].
man exports, see squash_gids. I would say there are some many holes with NFS that I am not sure it make any difference. The same apply to sendmail. > The issue here is that "group staff" is equivalent to "user root", and > that we should better eliminate such equivalence from the default system. No, it is not equivalent in the sense that if you are runing sgid staff and you do rm -r /usr/lib instead of rm -r /usr/local/lib by mistake, you do not hose your system. The first goal of the unix permissions is to protect against errors rather than malices. > > However, I disagree with the attitude of reassigning bug to > > debian-policy. If submitters want to make a policy proposal, > > they can propose it themselves. > > Well, you have to be an official developer for that, so that's not > always possible. > > In this case, you may consider this as a proposal made by me if you like. Oh, sorry then. I did not understand you backed the proposal. In that case, it was completly normal to reassign the bug here, of course. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]