From: utzoo!decvax!pur-ee!purdue!rlb
Newsgroups: net.unix-wizards
Title: su and suid compared
Article-I.D.: purdue.318
Posted: Mon Aug  2 22:49:45 1982
Received: Tue Aug  3 03:58:19 1982

It has been a long time since reading this news group and surely groups
of smaller granularity are needed to properly field this follow-up.

Mark Horton's original complaint about the inability to switch access
rights without losing context was a valid one and did not deserve a reply
in the tone of article 789 ("Blood-curdling su and newgrp" by dmr).

	In support of suid:

I wrote a similar program -- a worse version because it would write into
the swap file if necessary -- and we have been using "root", "unroot",
and "asroot" aliases for a year and a half.  Suid, despite it's inappropriate
implementation, allows a programmer to move freely and quickly (even
faster than su with Bourne shell) from standard privilege to root
privilege and back again.  An undesirable alternative is to su to root
and just stay there longer than necessary (who said keep access domains
as small as possible?*).

The issue at hand is into which program do you place the responsibility
of performing the inheritence of process-state (csh history, variables, dir
path, etc.)?  Hacking csh to pass on and acquire it, as suggested by
Ritchie, unnecessarily complicates the csh startup interface and
only solves the problem for one specific program.  On the other hand, using
a privileged program (suid) to pass augmented capabilities to a running
program is a progressive, though not new, idea.  Attacking the implementation
does not damage the concept.

Suid does add a feature to root's UNIX that was not previously available.
Su only allows one to start a new context - in fact, only a shell.  Suid
allows one to change the access domain of any process - for example, an
editor stopped at the user's terminal.

	In support of su:

In all fairness, I must admit I rarely use setuid (my version of suid)
anymore -- only when a small fire erupts and needs dowsing quickly.  Su,
once changed to scan $USER's .cshrc when switching to root, allows me
to have two csh's "running" simultaneously.  I su to root and suspend back
to rlb, then %su back to root.  This is really what I want most of the time.
I don't like to confuse root's work with rlb's work.  Other staffers,
however, who rarely need root's privilege, find setuid invaluable.

Even if user and group IDs are arranged "in appropriate ways," there will
still be a need to change the access domain of a running process.  Groups
hold more strength in access control than users, but only in Unix-utopia
can they be arranged to correctly handle several sometimes-overlapping,
sometimes-independent, usually-dynamic clusters of users.

This topic is interesting and doesn't deserve to be brushed off as a lose.

Bob Brown (rlb)
Purdue-CS (317)494-6530

*Peter Denning, right?