This is the mail archive of the
mailing list for the glibc project.
Re: Revisiting O_SEARCH and O_EXEC
- From: Rich Felker <dalias at aerifal dot cx>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Christoph Hellwig <hch at lst dot de>, libc-alpha at sourceware dot org
- Date: Mon, 5 Aug 2013 13:26:58 -0400
- Subject: Re: Revisiting O_SEARCH and O_EXEC
- References: <20130802173236 dot GA2491 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1308042134580 dot 25359 at digraph dot polyomino dot org dot uk> <20130805081947 dot GA5797 at lst dot de> <20130805121139 dot GE221 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1308051701070 dot 15287 at digraph dot polyomino dot org dot uk>
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
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...