tpc@leibniz.UUCP (Tom Chmara) (08/12/88)
We're in the process of trialing workstations to enhance our computing environment. (i.e. more and more people and their dogs are getting them). However, our support organization (the Evil Empire) is aghast that INDIVIDUAL USERS should want root access to their own workstations. I've been playing with UNIX for a while, and so should be expected to know why I (in particular) might want root perms on my machine. In particular, I'm interested in being able to give/receive NFS mounts to/from other machines in my group on an as-needed basis. As well, the lpr daemon will sometimes croak and need a kick in the pants. However, I'm drawing a blank at this point and start getting hot under the collar about the whole situation. The prevailing attitude in the E.E. is that people are going to mess up bad, that they don't need the access, and that they're going to be uneducated and irresponsible. I like to think better of my co-workers. Regardless, just because I claim that everyone here is of sterling quality doesn't wash. The bulk of the programmers here are NOT UNIX-familiar (caught one turning his workstation off&on because a program had hung, just like you would a MAC...) However, I like to think that the bulk of them are responsible and would not abuse the access. We're talking SUN, Apollo, HP, etc workstations here, most with local disks. Are there any cogent arguments for or (gulp) against root access? Is it just my own hunger for power over this inanimate box that is talking here? Please respond by email or news; as is SOP, I'll try to summarize in a few days... Thanks... ---tpc--- These aren't BNR's opinions. I don't often know my own mind, and you expect me to speak for someone else??
david@geac.UUCP (David Haynes) (08/13/88)
In article <125@leibniz.UUCP> tpc@leibniz.UUCP (Tom Chmara) writes: >...... However, our support organization (the Evil Empire) is aghast >that INDIVIDUAL USERS should want root access to their own workstations. > The prevailing attitude in the E.E. is that people are going to mess >up bad, that they don't need the access, and that they're going to >be uneducated and irresponsible. I like to think better of my >co-workers. Regardless, just because I claim that everyone here >is of sterling quality doesn't wash. As a system administrator in a (small) workstation environment, I think I should make a small plea for a voice of reason here. I don't, as a rule, give out root passwords to every Tom, Dick or Susan who asks for it, but I do give root access to those individuals who are competant enough (in my opinion) to have it. Why so? The releasing of the root password, even on a single workstation, can spell some long hours of recovery on your part as the result of a typical novice Unix user's mistake (such as rm * .tmp in the root directory). However, it is equally a pain in the ass to have to su somebody in and out of root perms because they are installing a package on their workstation that has root level daemons or requires other "high" privileges. Basically, I try to use common sense wherever possible. -david- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- David Haynes Geac Computers Canada Ltd. Telephone: +1 416 475 0525 350 Steelcase Road West, FAX : +1 416 475 3847 Markham, Ontario, CANADA. L3R 1B3 UUCP : utgpu!geac!david Official Keeper of the Canadian X11 Sources Repository
gwyn@smoke.ARPA (Doug Gwyn ) (08/14/88)
In article <125@leibniz.UUCP> tpc@leibniz.UUCP (Tom Chmara) writes: > Are there any cogent arguments for or (gulp) against root access? The most serious problem is that, in many networking implementations, super-user access on one system is tantamount to super-user access on all machines in the entire (local) network. The UNIX "super-user" UID should really be used only by privileged utilities, not by people. There should be NO NEED, in a properly configured system, for a person to type "su" in order to perform system-administrative actions.
denbeste@bgsuvax.UUCP (William C. DenBesten) (08/15/88)
From article <8338@smoke.ARPA>, by gwyn@smoke.ARPA (Doug Gwyn ): > In article <125@leibniz.UUCP> tpc@leibniz.UUCP (Tom Chmara) writes: >> Are there any cogent arguments for or (gulp) against root access? > > The most serious problem is that, in many networking implementations, > super-user access on one system is tantamount to super-user access on > all machines in the entire (local) network. Networks that have this problem are not properly set up. BGSU's network has 3 computers that are 'trusted hosts' to one another. Other machines are not in the trusted host list. This means that the machine that we allow entire classes (as in 30 students) to have su access to does not compromise the security of the rest of the computers. When you ftp, rlogin, etc from that machine, or any other machine on the network, it requires that you type the root password on the destination machine. > The UNIX "super-user" UID should really be used only by privileged > utilities, not by people. There should be NO NEED, in a properly > configured system, for a person to type "su" in order to perform > system-administrative actions. Yea, right. See my .signature. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- William C. DenBesten | denbeste@bgsu.edu Dept of Computer Science | CSNET denbeste%andy.bgsu.edu@relay.cs.net Bowling Green State University| UUCP ...!cbosgd!osu-cis!bgsuvax!denbeste Bowling Green, OH 43403-0214 | ------------------------------+---------------------------------------------- There is no difference between theory and practice in theory, but there is often a great deal of difference between theory and practice in practice.
vch@attibr.UUCP (Vincent C. Hatem) (08/16/88)
In article <8338@smoke.ARPA>, gwyn@smoke.UUCP writes: > The UNIX "super-user" UID should really be used only by privileged > utilities, not by people. There should be NO NEED, in a properly > configured system, for a person to type "su" in order to perform > system-administrative actions. We have a loosly-coupled network, and seeing as the machines are all over the place in two different buildings, I like the ability to use the data switch to fix a machine in the other building from my desk. Of course, I could walk over to the console, but I haven't got all day to be trudging all over the place, from console to console. - Vince -- Vincent C. Hatem | att ---->\ (available from any AT&T International | ulysses ->\ Action Central site) International Operations Technical Support | bellcore ->\ 1200 Mt Kemble Ave, Basking Ridge, NJ 07920 | ihnp4 ----->\__ !attibr!vch
maart@cs.vu.nl (Maarten Litmaath) (08/16/88)
In article <125@leibniz.UUCP> tpc@leibniz.UUCP (Tom Chmara) writes: >However, our support organization (the Evil Empire) ^^^^^^^^^^^ Huh? Do you get your workstations from the U.S.S.R.? I think that's pretty serious! :-) R.Reagan
sgf@ndc.UUCP (Fishman) (08/17/88)
I work on a diskless microVAX 2000, so I don't do my own system administration, but I occasionally _must_ have su privledge (sp?). That happens when my system must be rebooted, so I have to do a shutdown. Now, my system administrator _could_ walk around to every uVax in the building (we don't have all that many), and reboot them herself, but it's a lot easier for her to call me (and the other VaxStation folks) and ask me to do it myself. The root password on each VaxStation is different, and is different from the server's, so knowing it doesn't make it any easier to get root priveledges on the server. -- | Sharon Gates-Fishman | Speak for my employer? | | amdahl!cit-vax!ndc!sgf | Isn't it enough that I work for them? |
jwm@stdc.jhuapl.edu (Jim Meritt) (08/17/88)
Does this count sudo?
Disclaimer: Individuals have opinions, organizations have policy.
Therefore, these opinions are mine and not any organizations!
Q.E.D.
jwm@aplvax.jhuapl.edu 128.244.65.5 (James W. Meritt)sullivan@vsi.UUCP (Michael T Sullivan) (08/17/88)
In article <183@ndc.UUCP>, sgf@ndc.UUCP (Fishman) writes: > I work on a diskless microVAX 2000, so I don't do my own system > administration, but I occasionally _must_ have su privledge (sp?). > That happens when my system must be rebooted, so I have to do a > shutdown. Now, my system administrator _could_ walk around to Our 3B2 with SVR3.1 has a shutdown login. It is set up here as a non-login account, but in your case it could have a password on it so you can shut the machine down while still not su'ing to root. Is this possible on the uVAX? -- Michael Sullivan {uunet|attmail}!vsi!sullivan V-Systems, Inc. Santa Ana, CA sullivan@vsi.com "Your mother was a hamster and your father smelled of eldeberries! Pbbbt!"
barmar@think.COM (Barry Margolin) (08/17/88)
In article <183@ndc.UUCP> sgf@ndc.UUCP (Fishman) writes: >I work on a diskless microVAX 2000, so I don't do my own system >administration, but I occasionally _must_ have su privledge (sp?). >That happens when my system must be rebooted, so I have to do a >shutdown. Why not just make shutdown setuid root, and executable only by a group of which you are the sole member? These are the kinds of tools someone was referring to when he said that in a well-designed system you should rarely need to use "su". "su" should only be for unusual circumstances. Users shutting down their workstations is not unusual, so there should be a standard tool for it. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
limes@sun.uucp (Greg Limes) (08/18/88)
In article <183@ndc.UUCP> sgf@ndc.UUCP (Sharon Gates-Fishman) writes: >I work on a diskless microVAX 2000, so I don't do my own system >administration, but I occasionally _must_ have su privledge (sp?). >That happens when my system must be rebooted, so I have to do a >shutdown. Now, my system administrator _could_ walk around to >every uVax in the building (we don't have all that many), and >reboot them herself, but it's a lot easier for her to call me >(and the other VaxStation folks) and ask me to do it myself. Actually, this can be solved without giving the workstation owner the root password. Generate a small script that allows specific actions to be done, and wire it up to a maintenance login: maint::0:1:Maintenance Account:/:/usr/local/bin/maint Now give "maint" a password only known by the workstation's owner. This "maint" program can be as simple or as complex as the installation wants. For an even easier case -- I administer a small lab, containing eight workstations and a server. Sometimes I have to reboot machines, and frankly I would rather not stand there at the console waiting to log in as root. The solution? A "yoyo" account: yoyo::0:1:Bouncer:/:/yoyo with a script that runs /etc/fastboot, if and only if it is run from the console and there is nobody else on the system. No password needed. Generalize for your installation, tune for smoke. -- redhead [limes@sun.com] for uucp, backbone!ucbvax!sun!limes
morrison@ficc.UUCP (brad morrison XNX SE#) (08/18/88)
In article <183@ndc.UUCP>, sgf@ndc.UUCP (Fishman) writes: > I work on a diskless microVAX 2000, so I don't do my own system > administration, but I occasionally _must_ have su priviledge. > That happens when my system must be rebooted, so I have to do a > shutdown. Now, my system administrator _could_ walk around to > every uVax in the building (we don't have all that many), and > reboot them herself, but it's a lot easier for her to call me > (and the other VaxStation folks) and ask me to do it myself. > You could use a "shutdown" login, which could run the shutdown program as its "shell", with user id zero. The password could also be "shutdown". You could trap all of the interrupts, and even if someone was able to interrupt the program, all they'd get would be a login prompt. -- Brad Morrison Ferranti International Controls Corporation 12808 W. Airport Boulevard phone: (713) 274-5449 Sugar Land, TX 77478 UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!morrison
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (08/18/88)
In article <25952@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: >Why not just make shutdown setuid root, and executable only by a group >of which you are the sole member? /etc/shutdown is a script, but can be worked around. One other thing that must be done is to stay out of single user mode. If you go to single user from multi-user the user is made root. >These are the kinds of tools someone was referring to when he said >that in a well-designed system you should rarely need to use "su". >"su" should only be for unusual circumstances. Users shutting down >their workstations is not unusual, so there should be a standard tool >for it. Indeed. Isn't it rediculuous that the most mudane operations (backup, recover, creating users, etc.) on a eunuchs computer require the most powerful permissions possible. Sheesh. -- Larry Cipriani, AT&T Network Systems, Columbus OH, (614) 860-4999
zjat02@apctrc.UUCP (Jon A. Tankersley) (08/20/88)
Shutting down a system is easy to do. I'm not sure about security, but shutdown::0:1:Shutdown Request:/:/etc/shutdown.sh #!/bin/sh /etc/shutdown -h now Shutdown Request exit Seems to do the job for me. Also on other aspects of root - I have decided to go ahead and post this sucker..... I'd be more in favor of closing down root access than opening it up. It is one thing to have local root access only and to have that access leak onto other systems. Amoco has quite a few workstations at present, and very few root access personnel. When a requirement for root access presents itself one of the root people is called. We've been trying to log what that access involved and have developed quite a few 'asroot' functions that are fairly secure to do those 'precise' functions. The lpd is a good example. There is a resetprinter function in /usr/local/bin that will attempt to clear the lpd and printer if one exists. If this fails then I have to go back to work. The other people that have root access that aren't support personnel have that access and are logging its use so that more of these utilities can be developed, but early on problems developed. I had one making 10's of symlink's as root in /. Because he couldn't make it work as a user. Turned out that he had protections wrong on some directories, and he didn't think about the problem. Another problem we've had is in the area of backups. Because the dumps can't be initiated by non-root I have written some asroot functions to kick off a dump if the correct userid requests it. But this has some other problems when done across the network. Root access is required if you can't use the userid.host:/dev/mtdevice form. That 'feature' is also going away with newer releases of OS functionality and can't be portably counted as being there. Hence on our disk full systems root can access the major tape systems which are our diskless client servers. I don't want anybody in general to have THAT access. Screwing up on a diskless or small disk system is one thing, doing the same stuff accidently on a larger server is a whole different issue. If it weren't for the dump problem, it would not be as critical. We are addressing that by writing our own dump program.... Root access on all systems would be nice to open up for some things, but not everyone is UNIX-savvy. I've one person with 3 months UNIX experience (lots of other computer experience too) start using root for EVERYTHING on a shared system (I couldn't remove the root priv either). That is STUPID. He installed things that made assumptions of a specific environment trashed stuff of other users. It is possible that giving root access to users on workstations that they could create setuid things 'to get the job done, you understand' that would allow other to trip over and trash things. If it can happen on a shared system it can also happen in a workstation environment with shared resources. Just think of the goodies that most people share nowadays. I had a user that had a shell script that started emacs and looped to go back in after exiting emacs. Pretty simple. But 5 workstations started exhibiting no response. Seems that emacs didn't exit correctly when suntools was exited. Hogged the CPU. This was a non-root problem with UNIX in general. Adding root can add even more problems. THis is getting longer that I thought it was going to get... I am supposed to be writing a report. Wish report writing were as easy as some replies on the net. :-) Hope this helps some. Mounting Asbestos padding onto modem..... Placing fire baffles around CPU -tank- -- #include <disclaimer.h> /* nobody knows the trouble I .... */ -- #include <disclaimer.h> /* nobody knows the trouble I .... */
greywolf@unisoft.UUCP (The Grey Wolf) (08/23/88)
In article <887@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes: # In article <25952@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: # >Why not just make shutdown setuid root, and executable only by a group # >of which you are the sole member? # # /etc/shutdown is a script, but can be worked around. One other thing that # must be done is to stay out of single user mode. If you go to single user # from multi-user the user is made root. /etc/shutdown is a script only on SOME system V machines. On most machines I work with, it is an executable file. And, to boot, under Berkelix 4.x, it kills all the processes before going single-user on the console. That solves both problems. [NOTE: This is NOT to propogate another SysV/BSD war; they both have their points, good and bad.] # # >These are the kinds of tools someone was referring to when he said # >that in a well-designed system you should rarely need to use "su". # >"su" should only be for unusual circumstances. Users shutting down # >their workstations is not unusual, so there should be a standard tool # >for it. # # Indeed. Isn't it rediculuous that the most mudane operations (backup, # recover, creating users, etc.) on a eunuchs computer require the most # powerful permissions possible. Sheesh. geez, you mean I can't add users to my own system without becoming root? Aw, darn. I can chown things to other people so that they are the ones who appear to be taking up all the space on the system (under SysV, but then I guess SysV doesn't support quotas (if it did, accounting procedures would be for naught under current implementations, but this is another story)). # -- # Larry Cipriani, AT&T Network Systems, Columbus OH, (614) 860-4999 -- " Roan Anderson, Software Engineer, UniSoft Corporation, Emeryville, CA. (415) 420-6400 My opinions are my own, but if you're real nice, I'll share... [*] AT&T is a trademark of UNIX Inc. :-)