Re: root access for end users

ben <[email protected]> Sat, 06 Jun 2009 02:08:37 +0200
Newsgroups org.kernel.vger.linux-admin
Message-ID <[email protected]>
Yuri Csapo a écrit :
> After a battle of years, "academic freedom" was invoked and very senior 
> management, in its infinite wisdom, has decided that our users (mostly 
> researchers) should have root access (or full sudo, which amounts to the 
> same thing) to their Linux workstations.
> 
> Does anybody have experience running a Unix/Linux network like this?
> 
> Remember full sudo means the ability to 'sudo su' and become any other 
> user, making permissions (even across NFS) useless. It also means the 
> ability to play with/pilfer/replace Kerberos keytabs, allowing one to 
> impersonate any box to which they have access. The support nightmare 
> cannot be used as an argument against this because users have convinced 
> management that "that's what support is for."
> 
> All I can do is control the servers and decide how services will be 
> presented and which hoops users should go through to be able to use 
> server resources.
> 
> The current environment is basically Kerberos authentication, NIS 
> authorization and NFS/CUPS services. Most of the clients are owned, 
> built, maintained and supported by my organization, but some users will 
> use their new found freedom to build/buy their own boxes.
> 
> The plan is to move away from NIS to LDAP and from NFS to AFS.
> 
> What other problems do people see? Any thoughts and suggestions will be 
> greatly appreciated.
> 
> TIA!
> 
> Yuri

Really humbly, I'd just not recommend this full power to everybody if 
there are NFS shares.

In my really smaller case i did not hesitate to modify extensively 
default *nix groups (use me:staff instead of me:me, you:lab, her:lab
  -> man usermod) and forced people to use the "newgrp" command for each 
appropriate task (newgrp is really handy). I created groups for any kind 
of _role_ and added people into it (man groupadd, man usermod). Changed 
also path group, and group write access on the pathes to the appropriate 
staffs.

This could not do all what you need, but you can fine tune sudo for the 
rest. HTH
- ben
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html