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: net.sources
Subject: Re: Another kind of su program (source)
Message-ID: <198@olamb.UUCP>
Date: Thu, 12-Feb-87 07:31:35 EST
Article-I.D.: olamb.198
Posted: Thu Feb 12 07:31:35 1987
Date-Received: Thu, 19-Feb-87 06:27:31 EST
References: <195@olamb.UUCP> <263@aramis.RUTGERS.EDU>
Organization: AmbraSoft A/S (Denmark)
Lines: 45
Keywords: su(1), System administration, password-free su

In article <263@aramis.RUTGERS.EDU>, mende@aramis.RUTGERS.EDU (Bob Mende) writes:
> 
>   Here at rutgers we have a local hack that is called slide.  Slide
> is a program that can be as simple as
> 
> main{}
> 	{
> 	setuid(0);
> 	system(/bin/sh);
>  	}
> 
>   but ours makes a call to use your default shell (above is a simple
> sample).
> 
>   This program is owned by root and in group slide.  This is your 
> /etc/group you have a non-loginable (is that a real word??) group
> called slide.  Your system adminastrators, sysprogs, operators all
> are in group slide.  When they type slide they start up a new root
> shell.  A simple ^D and they are back to there normal shells.  Real
> simple and easy.  
> 

Sure I could have made the sus-program as simple as yours, but the main
feature in sus, is that you don't have to run a full-blown shell to
do your root-job. Running an interactive shell as root is always
dangerous, but sus can take a single command and execute it with
superuser priviledges! As in "sus vi /etc/passwd", it returns
immediary to your own shell after completion of the vi session. Most
of the users here who have been granted to use sus without password
will normally only have to do single commands, and there sus has
it's force.

I admit however giving the full priviledges of sus to many people
can be a security loophole, but no less than giving them the root
password. Another approach would be to reaarange the UNIX
permissions for the administrative commands, directories and files
to use a set-group-id approach, to give others a more priviledged
status but keeping the super-user priviledges to only one or two
people. But that would take much longer time to implement. And here
we only have three users who are allowed to use sus w/o password all
others have to know the super-users password (or the password for
the user they like to become).

					Kindly Regards
					Kim Chr. Madsen