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: Rich Felker <dalias at aerifal dot cx>
- To: Christoph Hellwig <hch at lst dot de>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 5 Aug 2013 08:11:39 -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>
On Mon, Aug 05, 2013 at 10:19:47AM +0200, Christoph Hellwig wrote:
> On Sun, Aug 04, 2013 at 09:38:38PM +0000, Joseph S. Myers wrote:
> > On Fri, 2 Aug 2013, Rich Felker wrote:
> >
> > > Another option, which I like better, is defining both O_EXEC and
> > > O_SEARCH to 3. This makes them look more like access modes, as they
> > > should, and avoids the need to change the definition of O_ACCMODE.
> > > However, I think this option would require agreement from the kernel
> > > folks, since it would be big trouble if they later wanted to use this
> > > value for something else. On the plus side, using the value of 3 would
> > > allow the kernel folks to explicitly support O_SEARCH and O_EXEC
> > > semantics kernel-side in the future, without help from the userspace
> > > library functions.
> >
> > *Whatever* the option I think it should be coordinated with the kernel in
> > the first place.
>
> *nod*
>
> I can't see any reason why implementing these two modes in libc would be
> preferable over doing it in the kernel. I could think of many reasons why it
> would be a bad idea.
>
> Rich, given that you're obviously interested in implementing this feature,
> how about you try to send patches implemnenting it in the kernel?
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
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).
FYI, having the macros in fcntl.h but non-working breaks packages
including coreutils.
Rich