Re: Revisiting O_SEARCH and O_EXEC

["Joseph S. Myers" <joseph at codesourcery dot com>]

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.

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

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

-- 
Joseph S. Myers
joseph@codesourcery.com