[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#484841: staff group root equivalence



On Mon, Mar 02 2009, Don Armstrong wrote:

> 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 roo

        Not quite. You see, us grad students in the staff group were
 _not_ supposed to be root, or be bale to modify the vendor directories
 (who knows, it might have violated the universities support contract).

        We were just give access to /usr/local, and /etc/ (not /usr or
 the like). The permissions were limited, and the group ACL was used to
 modulate _where_ in the file system one had god-like access.

        Unless my sudo-fu is entirely lacking, sudo access is command
 based, not path based.

        Not that it makes much of a difference in Debian selecting a
 default, really.  But I can see a use case in a large environment with
 subgroups where limited privileges are required -- and the /usr/local
 hierarchy, with the support for local overrides in path, programs like
 perl and emacs, made such setups easy for overlaying such privileges on
 a subset of the machines.

        manoj
-- 
Tact is the art of making a point without making an enemy.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


Reply to: