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