This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Revisiting O_SEARCH and O_EXEC
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Christoph Hellwig <hch at lst dot de>, <libc-alpha at sourceware dot org>
- Date: Mon, 5 Aug 2013 21:14:27 +0000
- 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> <20130805172658 dot GK221 at brightrain dot aerifal dot cx>
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