rlb (08/03/82)
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?nrh (08/03/82)
Actually, I thought dmr's response quite appropriate, although I sure would not have wanted to be in Mark's shoes. Personalities aside, dmr was right: If there ever was a hack-and-a-half, the /dev/mem scribbler is it. One can sympathize with the desire for a quick (is that REALLY important enough?) and context-maintaining (that is important!) method for becoming su. Perhaps the problem of how to maintain a program's "state" (c-shell history and variables) should be attacked. After all, it is just an accident that the uid is so easy to change. Changing the uid in /dev/mem is the sort of thing a programmer's soul suffers for in the afterlife.
trb (08/03/82)
My goodness, talk about fanaticism! This argument about becoming setuid root sound like a pro life/pro choice debate or some other such holy war. What are we looking at? A way to change the state of a process to allow it access to privileged functions. No more. Sounds to me like a job for a very simple system call, no more complicated than one which would poke the lights, back in the good old days when consoles HAD lights. It seems ridiculous to me that there isn't a quick and easy way to read and change all the non-volatile table information in the u and proc structures, in the whole operating system, that a user should have access to. Why does a ps have to take years to execute? Why should it be so painstaking to change a process uid? Dennis Ritchie was gagging about how kludgey the new code must look. He should be complaining about the data structures and their inaccessibility, not at our attempts to deal with them in the cleanest possible way under the circumstances. The outcry is such that I feel I must be missing a point somewhere. Would someone be so kind as to explain it to me? (And please type slowly.) Andy Tannenbaum Bell Labs Whippany, NJ (201) 386-6491