> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
