Re: O_NOACCESS?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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.

That actually makes the most sense, I think.  O_NOACCESS as I
implemented it a quick kludge to graft the effect I want onto the
existing framework.  It definitely is not the rightest answer,
especially with the ugly "works only when O_DIRECTORY is given" `fix'.

> (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.)

fexecve() makes a lot of sense too.  So would an flink(), and indeed f*
versions of any other call which uses a path just to name an object
rather than as a relevant part of the syscall.

But, taken to its logical conclusion, that also means that all the
pathname-taking calls should have versions which take a directory fd
and a single pathname component.  This would be nice in some respects,
though I'm not sure about bind(2) for AF_LOCAL sockets.  C is not a
right language for where my mind is going with this.

> #3, which is what I'd call O_NOACCESS, is something else though; [...]

> 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,

Actually, I don't think it would, not without creating other problems.
If it addresses my desire, then it must keep a reference to the
underlying object.  And if it does that, then it can be used as a DoS
by preventing large files (coredumps, logfiles) from being destroyed
upon unlinking them.

I'm not sure that needs fixing.  It does need more thought.

> 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.

What, if anything, did you do about the "anyone who can stat a file can
keep it around consuming diskspace indefinitely" issue?

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B