[ 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()
does)

>  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;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>