Date: Thu, 30 Oct 2003 15:57:35 -0800 From: andi payn <andi_payn@speedymail.org> To: freebsd-hackers@freebsd.org Subject: Re: O_NOACCESS? Message-ID: <1067558254.36829.2315.camel@verdammt.falcotronic.net> In-Reply-To: <1067528798.36829.2128.camel@verdammt.falcotronic.net> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1067558254.36829.2315.camel>