et@tornado.Berkeley.EDU (Eric Thompson) (10/02/90)
#4: What do they use this access for?
#5: Other info: do you have separate administrative passwords, or
other pseudo-root logins, and how are they implemented, etc.
Everyone's site is different, but I would like to collect information on
a lot of different sites to compare and make some decisions about my own.
Currently at my site there is discussion about who should have root access
and why, and a volume of answers to the above questions will help us see
how things work elsewhere.
Please EMAIL all responses to me at the addresses below. If you want a
summary or would like to see one posted, let me know.
Eric Thompson | et@ocf.Berkeley.EDU <- just my mail addresses
STONE ROSES & A'S BASEBALL | ...!ucbvax!ocf!et (not my sites)rickert@mp.cs.niu.edu (Neil Rickert) (10/02/90)
In article <1990Oct2.042650.15413@agate.berkeley.edu> et@ocf.Berkeley.EDU (Eric Thompson) writes: >#4: What do they use this access for? > >#5: Other info: do you have separate administrative passwords, or > other pseudo-root logins, and how are they implemented, etc. I created a front end command which allows those in the operator group to execute certain commands as if they were root, but without having to login as root. I named the command 'RootMode', and it sits in /operator. If executed directly it complains and exits. But if I make a hard link to it, also in /operator, with say the name 'lpc', then anyone in the operator group can execute /operator/lpc which just execs to the real /etc/lpc after first becoming root. This enables those who need root privileges for special purposes to gain them without needing to login/su as root. A syslog record is written for each access using this facility. Currently available commands by this procedure include: lpc, lpr, lprm - to deal with printer problems. dump - to make backup tapes. shutdown - to bring the system down gracefully. updatenameserver - a shell script to do a 'make' in the name server database directory, and to force a reload of the nameserver. (the above is not a complete list). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
blm@aquarium.ecn.purdue.edu (Brian L Moore) (10/03/90)
rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <1990Oct2.042650.15413@agate.berkeley.edu> et@ocf.Berkeley.EDU (Eric Thompson) writes: >>#4: What do they use this access for? >> >>#5: Other info: do you have separate administrative passwords, or >> other pseudo-root logins, and how are they implemented, etc. > I created a front end command which allows those in the operator group >to execute certain commands as if they were root, but without having to >login as root. > I named the command 'RootMode', and it sits in /operator. If executed >directly it complains and exits. But if I make a hard link to it, also >in /operator, with say the name 'lpc', then anyone in the operator group >can execute /operator/lpc which just execs to the real /etc/lpc after first >becoming root. This enables those who need root privileges for special >purposes to gain them without needing to login/su as root. A syslog record >is written for each access using this facility. This works, but if you have a highly networked environment, making all of the links everywhere can be a real pain in the rear. I have modified/written a "shell" that will do this, and is *much* easier to maintain, called vss(1), "Very Secure Shell". In this, the user can "live" in the shell, as you can with su'ing or logging in as root. However, only commands that you are authorized to use as root get executed with root permissions, anything gets passed to the shell with the normal user permissions. The operation of this is controlled with 2 control files. First of all, there is a file that lists the users that may use vss(1) and any commands they may run, such as: blm reboot, shutdown, dump, restore, etc..... If the person calling vss(1) is not in this file, then vss(1) simply prints and message and exits. If they are, however, the commands they may run as root are read in. When the user tries to run one of these commands, vss(1) looks in another file to find out where the command really is... shutdown /etc/shutdown reboot /etc/reboot ... and passed the command, along with the arguments, to a shell after doing a setuid() root. If the command the user gives is not in their permission list, the command line is simply passed onto the shell and executed as the caller uid. Any commands that are run as root under this setup are logged into a third file, so someone can keep an eye on what people are using it for. With this, a person doesn't have to be in a certain group to run things as root, control files are much easier to maintain (with rdist), and tighter control is kept over who can do what. If anyone is interested in a copy of the code, send me e-mail and I will get it to you. -blm -- Brian L Moore, Student Programmer | Purdue University Engineering Computer Network | internet: blm@ecn.purdue.edu MSEE Building, Room 104 | BITNET: BMOORE@PURCCVM W. Lafayette, IN 47906 (317) 494-5745 |