From mboxrd@z Thu Jan 1 00:00:00 1970 From: ben Subject: Re: root access for end users Date: Sat, 06 Jun 2009 02:08:37 +0200 Message-ID: <4A29B385.5060204@free.fr> References: <4A2902BF.8030903@mines.edu> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <4A2902BF.8030903@mines.edu> Sender: linux-admin-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="iso-8859-1"; format="flowed" To: Cc: linux-admin Yuri Csapo a =E9crit : > After a battle of years, "academic freedom" was invoked and very seni= or=20 > management, in its infinite wisdom, has decided that our users (mostl= y=20 > researchers) should have root access (or full sudo, which amounts to = the=20 > same thing) to their Linux workstations. >=20 > Does anybody have experience running a Unix/Linux network like this? >=20 > Remember full sudo means the ability to 'sudo su' and become any othe= r=20 > user, making permissions (even across NFS) useless. It also means the= =20 > ability to play with/pilfer/replace Kerberos keytabs, allowing one to= =20 > impersonate any box to which they have access. The support nightmare=20 > cannot be used as an argument against this because users have convinc= ed=20 > management that "that's what support is for." >=20 > All I can do is control the servers and decide how services will be=20 > presented and which hoops users should go through to be able to use=20 > server resources. >=20 > The current environment is basically Kerberos authentication, NIS=20 > authorization and NFS/CUPS services. Most of the clients are owned,=20 > built, maintained and supported by my organization, but some users wi= ll=20 > use their new found freedom to build/buy their own boxes. >=20 > The plan is to move away from NIS to LDAP and from NFS to AFS. >=20 > What other problems do people see? Any thoughts and suggestions will = be=20 > greatly appreciated. >=20 > TIA! >=20 > Yuri Really humbly, I'd just not recommend this full power to everybody if=20 there are NFS shares. In my really smaller case i did not hesitate to modify extensively=20 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 eac= h=20 appropriate task (newgrp is really handy). I created groups for any kin= d=20 of _role_ and added people into it (man groupadd, man usermod). Changed= =20 also path group, and group write access on the pathes to the appropriat= e=20 staffs. This could not do all what you need, but you can fine tune sudo for the= =20 rest. HTH - ben -- To unsubscribe from this list: send the line "unsubscribe linux-admin" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html