Re: O_NOACCESS?

From: andi payn (andi_payn_at_speedymail.org)
Date: 10/31/03

  • Next message: M. Warner Losh: "Re: stupid C language question" 
    To: freebsd-hackers@freebsd.org
Date: Thu, 30 Oct 2003 15:57:35 -0800

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

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: M. Warner Losh: "Re: stupid C language question"