Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!mcvax!diku!olamb!kimcm
From: kimcm@olamb.UUCP
Newsgroups: comp.sources.d
Subject: Re: Another kind of su program (source)
Message-ID: <199@olamb.UUCP>
Date: Fri, 13-Feb-87 08:20:10 EST
Article-I.D.: olamb.199
Posted: Fri Feb 13 08:20:10 1987
Date-Received: Thu, 19-Feb-87 06:27:51 EST
References: <195@olamb.UUCP> <263@aramis.RUTGERS.EDU> <608@vu-vlsi.UUCP>
Organization: AmbraSoft A/S (Denmark)
Lines: 49
Keywords: su(1), System administration, password-free su

In article <608@vu-vlsi.UUCP>, perry@vu-vlsi.UUCP (Rick Perry) writes:
: In article <263@aramis.RUTGERS.EDU> mende@aramis.RUTGERS.EDU (Bob Mende) writes:
: >
: >> Below is included a nice little feature program, it can be used as an
: >> alternative to su(1) or in conjunction with it.
: >
: >  Here at rutgers we have a local hack that is called slide.  Slide
: >is a program that can be as simple as
: 
: Both of these programs (performing password-free su) seem dangerous
: to me- if one of the authorized users were to accidently leave themself
: logged on, anyone could come along and su from their terminal.  Also,
: it makes the knowledge of an authorized sus/slide users password
: equivalent to knowing the root password.
: 
: ...Rick			..{cbmvax,pyrnj,bpa}!vu-vlsi!perry
: 			perry@vuvaxcom.bitnet

So what! as a SA you'll have to put you faith in people you give your trust.
The exact same thing could happen if you allow them to have the super-user's
password, and what have you gained a more complicated scenario.

Look at it this way: The people you give a simple and quick way to shift
between being themeselves and superuser, is less likely to run a permanent
super-user shell, thus reducing the risk of disasterous commands as rm'ing
everything. I wrote the sus program to allow certain users (especially myself
as SA) to just execute an arbitrary command as superuser and then return to
myself, or if that wouldn't suffice run a shell. But the hassle of giving
password each and everytime you want to remove garbage log-files wasn't worth
leaving the su(1)'ed shell so I just went on using the su-shell instead of
running as an unpriviledged user whenever possible! I know I'm kind of lazy
but aren't you?

The sus/slide approach also gives you the freedom to change the super-user
password as often as you like without having to inform the whole staff about
the new password, thus keeping the superuser passwd even more secure I admit
that sus, should never be allowed to be called from a dialup-terminal, but
just as the list of users who is allowed to use the program a list of
terminals from where it is allowed to use the program would be a great help.
This also solves some of the problems where people accidently leaves their
sus'ed terminal, because most SA's terminals are separated from the casual
user's terminals (in another room).

At last you're absolutely free to just make one entry in the allow file, for
yourself the SA - the program isn't meant to allow every user to become root.
If other users call the program it will act just as the normal su(1) cmd.

						Kindly Regards
						Kim Chr. Madsen