* Don Armstrong ([email protected]) [090302 22:16]: > On Mon, 02 Mar 2009, Manoj Srivastava wrote: > > This way, each research group had special privileges to their > > machines, but not any others, and the IT folks still had control. > > > > Similar things were done at some of the larger companies I worked > > for; so there is a use case. (And I think UNIX machines back in the > > 80's and early 90's came set up that way by default; I know Ultrix > > and OSF/1 did). > > It seems to me that most of these cases would be dealt with using sudo > now, as it would enable you to restrict the users to having root > access on a specific machine, since being in staff means being able to > trivially get root on that machine at any time.
I would like to get on with this bug report. To me, the situation looks as follows: Having write-access for group staff to /usr/local was a resonable decision when it was decided first. However, since then time went by, and it looks like most reasonable use cases disappeared. I agree with the principle of least surprise, and so I think we should change that behaviour. Ian said that we should require packages to create directories in /usr/local with mode 2755, so that permissions will be inherited. I agree that we should try to make it possible for users to keep a special group. However, I'm not sure if that's the best way to achieve it - I didn't try out but I'd assume that any directory in a deb won't get the group inherited from the parent directory. I think that a Post-Invoke-action in apt.conf would be the better way. (We should probably document that somewhere how to achive it.) Anyways, I think we should do the basic decision whether we want to /usr/local to be writeable by staff or not soon, and then try how to best do a transition. cheers, Andi -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
