From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 16:00:47 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AAFC16A4CE for ; Thu, 30 Oct 2003 16:00:47 -0800 (PST) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F9AB43FEC for ; Thu, 30 Oct 2003 16:00:46 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta13.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031030235736.PTZO20181.mta13.adelphia.net@[10.1.0.9]> for ; Thu, 30 Oct 2003 18:57:36 -0500 From: andi payn To: freebsd-hackers@freebsd.org In-Reply-To: <1067528798.36829.2128.camel@verdammt.falcotronic.net> References: <1067528798.36829.2128.camel@verdammt.falcotronic.net> Content-Type: text/plain Message-Id: <1067558254.36829.2315.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 30 Oct 2003 15:57:35 -0800 Content-Transfer-Encoding: 7bit Subject: Re: O_NOACCESS? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 00:00:47 -0000 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....