Re: O_NOACCESS?

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

On Feb 11, 2012, at 2:04 AM, Mouse wrote:

> I find myself wanting something I'm tentatively calling O_NOACCESS,
> which is basically "open for neither read nor write".  (I want this
> mostly so I can open a --x directory for fchdir() purposes.)
> 
> Looking at sys_open(), I see that one of the first checks it does is
> 
>        if ((flags & (FREAD | FWRITE)) == 0)
>                return (EINVAL);
> 
> I've tried what I think is the minial change: removing those lines,
> defining O_NOACCESS as 3, and making FFLAGS and OFLAGS correspondingly
> more complex.  It works, superficially.
> 
> I'm reasonably sure I haven't thought of all the implications; there's
> so much code involved that it's practically certain there's something
> somewhere that interacts with this in some way I haven't thought of.
> Anyone know of any reason it would be a Bad Thing to go with this?
> (Issues of compatability with POSIX or with kernels lacking this change
> are not what I'm looking for here; for my purposes at the moment, those
> are recognized and judged to be in the "don't care about" class.)
> 
> For the moment, 4.0.1 is of the most immediate practical import, but
> I'd be interested in issues specific to other versions too.
> 
The fine details (per later messages in the thread) are very important
and do need to be resolved.  That said, there's a strong philosophical
case for something like this (but perhaps not exactly this) to exist,
in that we have a permission setting (--x) corresponding to what you
want to do, but no set of open flags for it.  That's a violation of
orthogonality, which frequently points to missing features.  (Aside:
something that corresponds to --x semantics for directories solves
the special file problem, because this type of open would not apply to
them: --x is not applicable to special files, only to directories and
executables.)


                --Steve Bellovin, https://www.cs.columbia.edu/~smb