Revisiting O_SEARCH and O_EXEC

[Joseph S. Myers]

On Mon, 5 Aug 2013, Rich Felker wrote:

> 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?

linux-api@vger.kernel.org (it doesn't tend to be very actively used).

> > 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...

It's not at all clear to me they can be done 100%-correctly in the absence 
of O_PATH kernel support.  In particular, undesired side effects from 
opening a device without O_PATH can't be avoided (without races) in any 
way I can see (and my point is that security issues arising from O_SEARCH 
and O_EXEC in this case should be considered to be instances of the same 
security issue as if the user directly passes O_PATH, which comes from the 
kernel choice not to give errors for unknown O_* flags, and that we 
shouldn't specially try to reject any of the three flags in userspace in 
that case any more than we try to validate other O_* flags passed to the 
kernel for the possibility that an old kernel may not implement all the 
desired semantics and so security issues may arise).

-- 
Joseph S. Myers
joseph@codesourcery.com