Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt.cs.cmu.edu!sei.cmu.edu!dvk
From: dvk@sei.cmu.edu (Daniel Klein)
Newsgroups: net.arch
Subject: SUID Patent
Message-ID: <356@aw.sei.cmu.edu.sei.cmu.edu>
Date: Wed, 1-Oct-86 10:28:31 EDT
Article-I.D.: aw.356
Posted: Wed Oct  1 10:28:31 1986
Date-Received: Sat, 4-Oct-86 01:35:39 EDT
Sender: netnews@sei.cmu.edu
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 26
Keywords: Was: 68000 MemMgt, Bechtolsheim, SUID

The JACCT bit on the TOPS system is not quite the same as the SUID bit in
Unix systems.  The fundamental differences are:

The kernel does not have to be recompiled to include a new SUID program.
MOST importantly, though (and here is where the point is being missed), is
that ANY user may make a program SUID.  This does NOT mean that the user
running this program becomes root (i.e. user [1,2]).  What is DOES mean is
that the runner becomes the same UID as the owner of the program.  Many SUID
programs are owned by root/sys/bin, but they can be owned by anyone.  The
reason for SUID is that in general you cannot trust users to be nice enough
to setuid to someplace nice if you start them out as root.  TOPS was a lot
less anarchistic than Unix is.  I do not WANT to allow Joe Random User to
write code (with a potential Trojan Horse in it), and have him get a JACCT
equivalent.  All that s/he can do is write a program that will allow anyone
to access only his files, not the rest of the systems.

For other (hopefully interesting) reading, take a look at my article in the
Dallas Usenix proceedings (Winter 1985), on a capability based protection
scheme under Unix (using SUID and a few other neat tricks).
--
==-------------==-------------==-------------==-------------==-------------==
Daniel V. Klein, who recently gave up a lucrative job as a freelance consultant
to go work for the warmongering SEI, and is, frankly, enjoying himself.

		ARPA:	dvk@sei.cmu.edu
		USENET:	ucbvax!dvk@sei		(questionable link)