Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!cbmvax!vu-vlsi!perry
From: perry@vu-vlsi.UUCP
Newsgroups: comp.sources.d
Subject: Re: Re: Another kind of su program (source)
Message-ID: <609@vu-vlsi.UUCP>
Date: Tue, 3-Feb-87 00:08:41 EST
Article-I.D.: vu-vlsi.609
Posted: Tue Feb  3 00:08:41 1987
Date-Received: Wed, 4-Feb-87 03:21:43 EST
References: <4055@caip.RUTGERS.EDU>
Reply-To: perry@vu-vlsi.UUCP (Rick Perry)
Organization: Villanova Univ. EE Dept.
Lines: 25
Keywords: su(1), System administration, password-free su

In article <4055@caip.RUTGERS.EDU> brisco@caip.RUTGERS.EDU (Thomas Paul Brisco) writes:
>...
>	As with any type of root access, there are security holes, but
>we feel we have minimalized them. What better to trust? Giving out the
>root password (to be written down, forgotten, changed) or to trust a
>person to not leave a logged in job unattended?

   What we have been doing is to have separate root logins for each user that
can su.  The login directory for these su's are in sub-dir's of the normal
user's login.  For example, ~perry is my normal login, and 'su rickp'
makes me root with $HOME as ~perry/rickp.  That way, each su has a separate
tcsh .history file which can be useful not only for the user, but also handy
in backtracking when someone screws up something.  Also, an individual su
can be easily deleted without having to change a global root password and
notify everyone [and that's a nice feature of the 'sus' access file and
'slide' group stuff too, agreed].

   I do see the usefullness of the sus/slide password-free su's for people
who need it a lot and are hassled by always having to type a password in
the normal setup.  I was really tempted to make something like that here
but have decided against it due to paranoia I guess.  Also, we only have
four su's, perhaps the management situation would be different if we had
20 or more...

...Rick