Re: Revisiting O_SEARCH and O_EXEC

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Aug 05, 2013 at 05:19:01PM +0000, Joseph S. Myers wrote:
> On Mon, 5 Aug 2013, Rich Felker wrote:
> 
> > The kernel folks position from the beginning (see the early threads
> > where O_PATH was added) seems to be that they think they've provided
> > enough for O_SEARCH and O_EXEC and that they don't want to design to
> > POSIX but instead design something that's general enough to provide
> > what POSIX requires. I think this is misguided, but I don't want to
> 
> The O_* flags occupy a space shared by userspace and the kernel.  If we're 
> to use flags in any way that is not a simple pass-through (which does seem 
> like an unfortunate complication where otherwise functions could just be 
> implemented through syscalls.list), then coordination with the kernel is 
> needed to avoid any future cases where flag values used with libc 
> functions become meaningful with the corresponding kernel syscalls, but 
> with different semantics.

I agree completely that we need _agreement_ with the kernel folks on
how the flags will be used, but I don't think we'll get them to do the
work in kernelspace without a fight, and even if we win, we'd still
need to have fallbacks for pre-3.11 kernels.

I've emailed LKML about this but gotten no response. Perhaps I should
try that linux-api mailing list. What is the address for it?

By the way, I don't think the kernel developers were aware of the
O_NOFOLLOW issue and the fact that we can't simply define O_SEARCH and
O_EXEC as O_PATH and be done with it.

> > have that argument. In any case, adding it to the kernel only is
> > useless because userspace won't be able to provide it until everybody
> > has switched to Linux 3.11+. That'll be 10+ years. Userspace must
> > provide it with what we have to work with as long as Linux 2.6 is
> > relevant (supported by the libc).
> 
> It's perfectly reasonable for some libc features to depend on appropriate 
> kernel support, although certainly it's desirable to support them as far 
> as possible on older kernels (e.g. through fallback code emulating using 
> O_PATH).

*nod*

For what it's worth, I believe we have fully conforming support for
O_SEARCH and O_EXEC in musl modulo the O_NOFOLLOW issue, and it works
acceptably well even on pre-O_PATH kernels (i.e. works except that the
open fails if you don't have read access). So once we resolve this
issue, we should be at 100%.

> > FYI, having the macros in fcntl.h but non-working breaks packages
> > including coreutils.
> 
> It's not clear glibc should try to do any better than the kernel regarding 
> graceful failure modes in the absence of kernel support (that is, for 
> glibc to try to give accurate ENOSYS or similar errors when the kernel 
> support needed for the proper semantics of a given O_* flag isn't present, 
> when the kernel practice is to ignore unknown flags, and in general the 
> user may wish to pass through values unknown to glibc when their kernel is 
> newer than their glibc).  Universal practice in glibc is that header 
> values are defined and functions declared for features in the newest 
> kernels even though the kernel in use at runtime may not support them.

Historically glibc has emulated a lot of things on older kernels (at*
functions, per-thread cpu clocks, etc..) as well as things not even
supported by the kernel (like euidaccess). Some of these emulations
have been very poor-quality, but I believe O_SEARCH and O_EXEC are
trivial to do 100%-correctly, so I don't see any good justification
for omitting them. Moreover, like I said, the kernel folks do not seem
receptive to adding functionality specific to the POSIX definitions of
these access modes in kernelspace...

Rich