Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.bugs.uucp,net.news.adm
Subject: Re: mkdir() under suid
Message-ID: <3230@sun.uucp>
Date: Mon, 10-Feb-86 15:16:59 EST
Article-I.D.: sun.3230
Posted: Mon Feb 10 15:16:59 1986
Date-Received: Wed, 12-Feb-86 20:10:26 EST
References: <495@kepler.UUCP> <714@laidbak.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 49
Xref: watmath net.bugs.uucp:693 net.news.adm:510

> Either of two features from the 4.2BSD kernel would avoid these
> problems:
> 
> 	o Allowing one to set the real uid from the effective one
> 	  with setuid(geteuid()).
> 
> 	o A mkdir() system call, which avoids all of the real vs.
> 	  effective uid problems in the first place.
> 
> The former is a sufficient solution, and one which I would like
> to see in System V.

The former is a *necessary* solution to the protection problems introduced
by S5's looser rules for when a process can send a signal to another
process.  Those rules permit a process to send a signal to another process
iff the real or effective UID of the sending process matches the real or
saved set-UID UID of the receiving process.

Consider a set-UID program like "uucico".  If run as the result of a user
directly or indirectly (e.g., from "mail") running a UUCP job queueing program
like "uucp" or "uux", it runs with the real UID of that user.  This means
that the user can do a "kill -9" on that "uucico" and have it "take".
Furthermore, since "uucico" cannot set its real UID to match its effective
UID (unless it is run as set-UID to "root" and sets them both to the UUCP
account), it cannot protect itself from this.

> The latter, while useful, does not *really* have to be in the kernel;
> hence, it does not belong there.

No.  "mkdir" would have to be grossly hacked-up in order to know, *in
advance*, all the file system types it could be asked to make a directory
on.  (You say that it will only be ased to make a directory on a UNIX file
system?  Try again.  Sun's NFS, for instance, can be implemented on non-UNIX
systems.  Furthermore, the "virtual file system" layer that NFS is built on
top of permits Sun UNIX to support non-UNIX file systems, such as the MS-DOS
file system.  Version 8 has a similar mechanism, although I don't know if it
can support non-UNIX file systems.)

"mkdir" is an abstract operation, just like "creat" is.  The same module
which implements the "create a file" operation - namely, the UNIX kernel, in
present-day UNIX systems - should implement the "create a directory"
operation (which is NOT the same as the "make a node of type directory"
operation; "create a directory" also involves making the "." and ".." links,
at least on UNIX file systems, and may be totally unrelated to a "make a
node" operation on a non-UNIX file system).
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy%gorodish@sun.arpa	(yes, really)