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?