Subject: Re: funlink() for fun!
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Greg A. Woods <>
List: tech-kern
Date: 07/12/2003 15:02:07
[ On Saturday, July 12, 2003 at 01:48:29 (-0400), der Mouse wrote: ]
> Subject: Re: funlink() for fun!
> > If you get the wrong answer from facess() then you just close() the
> > file and no harm is done (unless
> ...the file is really a tape device and you've just unloaded the
> evening's backup tape by opening it and closing it.
> You _cannot_ safely do a privileged open of untrusted pathnames.
> (Thinking that access() permits this is an example of the confusion
> about what access() does and doesn't do.)  The only way to get it right
> is to run as the appropriate user when doing the open (or, if
> available, use an open() variant that does the equivalent internally).

OK, well then if you're going to worry about the side effects of
accidentally opening a device then let's put open_as_user() in the
kernel.  That's the only safe solution that avoids the overhead of a
fork() and the subsequent file descriptor passing, and also avoids the
danger of ever allowing a process to regain privilege after it has
discarded privilege.

(even my non-descriptor passing implementation would violate your device
side-effect rule....)

> The former have obvious f* analogs, though the f* analog of open()
> doesn't exist (no, it's not dup(2)).

There can be no fopen() analog of open(), though dup() is indeed the
closest like thing.  Open() operates on pathnames, not files!  ;-)
(open() only references files -- it doesn't change them like unlink()

>  The latter would need
> directory-fd-and-string pairs to have real f* analogs.

No, they don't really -- fchdir() is still the best solution (even if it
does mean adding O_NOACCESS and/or openpwd())

								Greg A. Woods

+1 416 218-0098;            <>;           <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>