From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 15:13:45 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 2508416A4CE for ; Fri, 31 Oct 2003 15:13:45 -0800 (PST) Received: from mta4.adelphia.net (mta4.adelphia.net [68.168.78.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id F360F43FDF for ; Fri, 31 Oct 2003 15:13:43 -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 <20031031230105.IEGX20181.mta13.adelphia.net@[10.1.0.9]>; Fri, 31 Oct 2003 18:01:05 -0500 From: andi payn To: "M. Warner Losh" In-Reply-To: <20031031.142959.33240958.imp@bsdimp.com> References: <1067628015.825.64.camel@verdammt.falcotronic.net> <20031031.130229.132929054.imp@bsdimp.com> <1067635232.825.202.camel@verdammt.falcotronic.net> <20031031.142959.33240958.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1067641263.825.298.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 15:01:04 -0800 Content-Transfer-Encoding: 7bit cc: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org 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 23:13:45 -0000 Before I go any further, I'd like some indication of whether this is worth pursuing. In particular, if any device driver issues can be resolved easily, and if the FFLAGS conversion is efficient enough (I'll look into whether it's better to do this the linux way, or to use slightly more complicated FFLAGS and OFLAGS macros), is this a good idea, or a bad one? I personally think that being able to fstat anything you can stat, fchdir anything you can chdir, add ioctl's that don't require read access, etc. would be a good thing. And of course my original motivation (being able to kqueue-monitor any vnode you can stat) also still sounds like a good one to me. However, if nobody agrees, I'll drop it. Meanwhile: On Fri, 2003-10-31 at 13:29, M. Warner Losh wrote: > In message: <1067635232.825.202.camel@verdammt.falcotronic.net> > andi payn writes: > : > : Are there any other special devices like this in FreeBSD? > : > > : > Rewind units on tape drives? If there's no access check done, and I > : > open the rewind unit as joe-smoe? The close code is what does the > : > rewind, and you don't have enough knowledge to know if the tape was > : > opened r/w there. > > Actually, it looks like there's a flags parameter passed to close, > which I think could be used to 'know'. No one uses it now. > > : Thanks; that's a good example. Do you have an example of a specific > : driver so I can look at the code and see what would need to be done? > > src/sys/cam/scsi/scsi_sa.c. OK, thanks again. While it looks like the problem you mentioned would be easy to work around, I can see a few other potential problems here. For example, the driver seems to give anyone who opens its device an inherent exclusive lock: a successful open always sets SA_FLAG_OPEN, and anyone who tries to do an open when SA_FLAG_OPEN is set will get an EBUSY no matter what. (Notice that linux's st_open has similar issues, and this doesn't cause a problem in linux--I'll have to look deeper to see why.) I'd assume other drivers might have similar issues--in fact, a quick scan shows a handful of other devices that would need to be checked. Presumably, the way this _should_ work is that opening a device file with O_NOACCESS shouldn't create a lock, set up for any kind of special handling on close, or do anything else except give you an fd. And of course that fd shouldn't be usable for anything you shouldn't be allowed to do (that is, it can be fstat'd iff the file you opened could be stat'd, etc.). Next time I reboot to linux, I'll check what it does in a variety of similar cases (and trace through the kernel if it's not obvious how and why).