Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: NFS and many thousands of user-id's
Message-ID: <32716@sun.uucp>
Date: Tue, 3-Nov-87 02:30:47 EST
Article-I.D.: sun.32716
Posted: Tue Nov  3 02:30:47 1987
Date-Received: Fri, 6-Nov-87 22:08:16 EST
References: <7605@g.ms.uky.edu> <7623@e.ms.uky.edu>
Sender: news@sun.uucp
Lines: 51

DISCLAIMER:  none of this in any way reflects Sun Microsystems policy.  If you
want to know something about what the merged OS will end up as, or whether any
of the stuff described in the paper described below will end up in a SunOS
release, ask your sales office, or some official Sun Microsystems
spokescritter, for the official story.  (I write code, I don't make policy.  On
the whole, I'm just as glad I don't.)

> Consider the following situation.  You're root on a machine that serves
> part of it's filesystem.  You put a /bin/sh somewhere and make it setuid
> to root etc.  Then you go over to another machine and execute that /bin/sh.
> Voila you're root over there.

Not if the machine that's mounted that file system has mounted it "no-set-UID."
The ability to say "don't believe set-UID bits when running programs from this
file system" has been in SunOS since at least release 3.2.  I don't know what
other UNIX systems supporting NFS client code implement this, although I
presume at least some of them have picked it up.

> But we hadn't thought through the consequences of AT&T and Sun merging the
> many-varied threads of Unix into one.  Part of this means a merging of NFS
> and RFS.  (Will they meet halfway and call it PFS???) :-)

Merging System V and 4BSD makes sense; the two systems are (opinions to the
contrary nonwithstanding) recognizably descended from Research UNIX, and the
true differences (as opposed to the "system A has this feature and system B
doesn't" differences - those can largely be handled by adding the feature in
question to system B) can generally be handled by providing multiple
environments (not necessarily complete universes; it doesn't make sense to
provide e.g. two versions of "egrep" or "stat" when you can provide one that's
compatible with both, which you can do).

"Merging NFS and RFS" is a different story.  The two did not start from the
same design or the same code; it's not a question of making small changes or
providing small mode switches to make something that can look like either.  It
strikes me as similar to merging C and Pascal (as opposed to e.g. merging
vendor X's and vendor Y's extensions to Pascal).

You can certainly make a system that supports both as independent mechanisms;
it could support other remote data access mechanisms as well.

> Since RFS has some of the proper security features, and the NFS people
> know the problems already, then this will probably be fixed around SysVr10.

There are other ways of dealing with this problem than by doing straight UID to
UID mapping.  See "Secure Networking in the Sun Environment", by Brad Taylor
and Dave Goldberg, in the 1986 summer USENIX proceedings.  (Also note that
straight UID to UID mapping doesn't work if both systems don't support
UNIX-style UIDs.)
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com


Brought to you by Super Global Mega Corp .com