O_NOACCESS?

[andi payn]

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 at verdammt.falcotronic.net>
>             andi payn <andi_payn at speedymail.org> 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).