Workstations: good reasons for owner root access

[Jon A. Tankersley]

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