Re: O_NOACCESS?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Feb 11, 2012 at 05:02:27PM -0500, Steven Bellovin wrote:
 > The fine details (per later messages in the thread) are very important
 > and do need to be resolved.  That said, there's a strong philosophical
 > case for something like this (but perhaps not exactly this) to exist,
 > in that we have a permission setting (--x) corresponding to what you
 > want to do, but no set of open flags for it.  That's a violation of
 > orthogonality, which frequently points to missing features.  (Aside:
 > something that corresponds to --x semantics for directories solves
 > the special file problem, because this type of open would not apply to
 > them: --x is not applicable to special files, only to directories and
 > executables.)

There are, however, at least three possible things there's currently
no open flags for.

(1) search/lookup on a directory, as described;
(2) execute on an (executable) regular file;
(3) really nothing at all.

#1 and #2 could be legitimately combined (as the --x permission
setting is combined) into something we could reasonably call O_EXEC.
(Note that while there may be no use for #2 in userlevel code, unless
perhaps if we add an fexecve() call, having it would be convenient in
the kernel.)

#3, which is what I'd call O_NOACCESS, is something else though; it
would allow implementing stat() using fstat() as follows:

   int
   stat(const char *path, struct stat *buf)
   {
           int fd;

           fd = open(path, O_NOACCESS);
           if (fd < 0)
                   return -1;
           if (fstat(fd, buf)) {
                   close(fd);
                   return -1;
           }
           close(fd);
           return 0;
   }

That is, it would let you use open() to create a fd for any path you
can name, including devices and whatever else, without granting any
access permissions at all. And, indeed, without calling device-level
open() routines and such.

This would also support what Mouse is trying to do, and would make
more sense as an alternate to O_RDONLY/O_WRONLY/O_RDWR than an O_EXEC
would... as it does make sense to use O_RDONLY|O_EXEC for some
directory accesses, and if we had fexecve(), O_WRONLY|O_EXEC would
make sense for creating and executing temporary files.

I have implemented #3 in research kernels and it doesn't cause the
world to blow up, although it does require some extra logic for
calling device open routines, and NetBSD in particular might be
missing checks entirely in certain places (like flock, as previously
cited) that would need to be added.

-- 
David A. Holland
dholland%netbsd.org@localhost