Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!prls!mips!dce
From: dce@mips.UUCP
Newsgroups: comp.unix.wizards,comp.unix.questions,comp.bugs.4bsd
Subject: su modifications posted to net.sources
Message-ID: <160@quacky.mips.UUCP>
Date: Wed, 4-Feb-87 11:49:53 EST
Article-I.D.: quacky.160
Posted: Wed Feb  4 11:49:53 1987
Date-Received: Sat, 7-Feb-87 11:05:17 EST
Reply-To: dce@quacky.UUCP (David Elliott)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 55
Xref: watmath comp.unix.wizards:838 comp.unix.questions:922 comp.bugs.4bsd:172


I have posted 3 articles to net.sources: modifications to /bin/su (described
below), manual page modifications, and a new manual page.

Some background: When I worked in commands development at Tektronix, I
implemented an idea brought up by the Small Systems Support Group, which
was to add an option to su to cause it to retain all of the current
environment, including the shell. That is, instead of me becoming user X,
using user X's shell, and other parts of X's environment, I would get
the permissions of user X, but retain my shell, aliases, home directory,
and so forth.

When I came to Mips, there existed a command called "ssu". This command
set the userid to 0 and executed "/usr/local/bin/csh" or, if commands were
given on the command line, the specified commands. The userids of the
people allowed to use the command were compiled into the code. This command
was nice, but lacked some things such as system logging and group setting.

Finally, when 4.3BSD was released, I found that it required users to be
in group wheel (group 0, for you non-BSD types) to be able to su. This was
not acceptable to us in our development environment.

Taking all of this into account, I decided to provide some new functionality
for su:

	1. -e option retains the environment
	2. -c option causes su to execute any arguments given after the
		username directly, instead of passing them to the shell
	3. If the effective groupid is 0, the user does not have to be
		in group 0 (this can be effected by making su setgid(0))
	4. If called as "ssu", the command line is parsed as if it was
		'su -e -c root {user-supplied arguments}', so 'ssu vipw'
		is the same as 'su -e -c root vipw'
	5. For su'ing to root, the file /etc/su_people is searched to see
		if the user can su without a password

In order to provide more security, su_people must be mode 600, owned by
userid 0, and have groupid 0. In order to aid in maintaining this file
in a network of many hosts, the su_people entries may have a list of
hosts for which the user is authorized, or a list of hosts for which the
user is not authorized.

The su_people file only applies to root, since we found that it was
easier to implement and maintain, and since you can always say something
like

	ssu su -c news /usr/lib/news/expire -e 10

if you want to run expire as news.

Comments and suggestions are welcome.
-- 
			David Elliott

UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD:  	408-720-1700