O_NOACCESS?

[andi payn]

On Thu, 2003-10-30 at 07:46, andi payn wrote:
> As far as I can tell, FreeBSD doesn't have anything equivalent to
> linux's O_NOACCESS (which is not in any of the standard headers, but
> it's equal to O_WRONLY | O_RDWR, or O_ACCMODE). In linux, this can be
> used to say, "give me an fd for this file, but don't try to open it for
> reading or writing or anything else." 

I've been playing with this. I took out the test for ((flags &
O_ACCMODE) == O_ACCMODE) in kern_open (in sys/kern/vfs_syscalls.c), and
modified FFLAGS and OFLAGS (in sys/fcntl.h) to wrap around the lower two
bits (so 3, O_ACCMODE, becomes 0), then rebuilt everything. 

Everything seems to work as well as ever--as I expected, since only
programs that depend on using open(O_ACCMODE) to get an EINVAL should be
surprised. 

I suppose the slightly-more-complicated FFLAGS and OFLAGS macros is
slowing down my system to a some degree, although there's no slowdown
that I can tell by normal use, or by running benchmarks. Still, if I
knew every place the fflags result was used, it would probably be better
to use simpler macros wherever possible (usually the only part you need
is FREAD | FWRITE, but not always).

However, I haven't yet tested what all of the different vfs modules do
when opening or processing a file with !FREAD and !FWRITE. I also
haven't tested actually using O_ACCMODE yet--to see if I can get an fd
for a file I have no access to, verify that it won't let me read or
write on that fd, make sure I'm allowed to close it, etc.

Can anyone think of anything I should expect to go wrong? Or, more
important, anything I should test that I seem to have missed?

Meanwhile, I've been looking into where this is used in linux, and other
than internally (for symlinks), it seems like opening with neither read
nor write access is only used by lilo (and lilo also does all kinds of
other weird things--like opening with mode -1 for passthrough). 

I thought the dnotify utility or the fam dnotify patch would do this
(anything you can stat, you should be able to monitor), but I was wrong.
So maybe this isn't a very useful feature anyway. On the other hand,
just because the dnotify patch for fam doesn't take advantage of it
doesn't mean a kqueue patch for fam shouldn't....