Subject: Re: funlink() for fun!
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Greg A. Woods <firstname.lastname@example.org>
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
(even my non-descriptor passing implementation would violate your device
> 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; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>