Very Computer

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

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.

Quote:> 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.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


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.

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  

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?     |

Does this count sudo?

Disclaimer: Individuals have opinions, organizations have policy.
            Therefore, these opinions are mine and not any organizations!
Q.E.D.

--
Michael Sullivan                                {uunet|attmail}!vsi!sullivan

"Your mother was a hamster and your father smelled of eldeberries!  Pbbbt!"

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.

{uunet,harvard}!think!barmar

        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.

   for uucp, backbone!ucbvax!sun!limes

Quote:>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.

--
Larry Cipriani, AT&T Network Systems, Columbus OH, (614) 860-4999

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 .... */

/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. :-)