Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!jhunix!doug From: doug@jhunix.HCF.JHU.EDU (Douglas W O'neal) Newsgroups: comp.admin.policy Subject: Re: Policies concerning root privs Message-ID: <8560@jhunix.HCF.JHU.EDU> Date: 5 Jun 91 13:20:40 GMT References: Organization: The Johns Hopkins University - HCF Lines: 35 In article I'm sure this has been discussed to death in other groups, but I ->haven't seen it and this seemed to be an appropriate place. -> ->I am responsible for some 40 workstations. These workstations are all ->connected to the Internet, and are dispersed among 18 different ->groups, each of which would like to have root privileges on their ->machines. -> ->Is this a good/bad idea? What policies have various sites developed ->to deal with this question? If it's a bad idea, what are various ->methods for dealing with groups that demand they have root privilege? ->Any advice for sites on how to approach revoking privileges? I am in a similar situation here. In each department, one contact has the root password, but they do not use the root account except when something goes wrong (printer stalls, machine crashes, etc.) AND I am not available. This means there might be some delay in services occasionally, but hopefully the machine is administered correctly and consistently. There is one exception to the rule of the departments not messing with root (a department that I cannot forbid messing with the system :( ) has given be more grief that all the other departments combined. My advice: let the departments know that you want to restrict root access as much as possible. Then change the passwords and give a copy of the password in a sealed envelope to one contact in the department. If they need to use it, have them let you know afterwards. Doug -- Doug O'Neal, Distributed Systems Programmer, Johns Hopkins University doug@jhuvms.bitnet, doug@jhuvms.hcf.jhu.edu, mimsy!aplcen!jhunix!doug Like many of the features of UNIX, UUCP appears theoretically unworkable... - DEC Professional, April 1990