This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: C11 threads ABI questions - enum values
- From: Rich Felker <dalias at libc dot org>
- To: Christoph Hellwig <hch at lst dot de>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Sat, 4 Oct 2014 18:57:56 -0400
- Subject: Re: C11 threads ABI questions - enum values
- Authentication-results: sourceware.org; auth=none
- References: <20141002001720 dot GO23797 at brightrain dot aerifal dot cx> <20141002214229 dot 734B62C3A2F at topped-with-meat dot com> <20141002222958 dot GR23797 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1410031038300 dot 26280 at digraph dot polyomino dot org dot uk> <20141003151917 dot GS23797 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1410031527460 dot 14538 at digraph dot polyomino dot org dot uk> <20141003153248 dot GT23797 at brightrain dot aerifal dot cx> <20141003183910 dot GA8806 at lst dot de> <20141003194932 dot GU23797 at brightrain dot aerifal dot cx> <20141004175346 dot GA23717 at lst dot de>
On Sat, Oct 04, 2014 at 07:53:46PM +0200, Christoph Hellwig wrote:
> On Fri, Oct 03, 2014 at 03:49:32PM -0400, Rich Felker wrote:
> > On Fri, Oct 03, 2014 at 08:39:10PM +0200, Christoph Hellwig wrote:
> > > On Fri, Oct 03, 2014 at 11:32:48AM -0400, Rich Felker wrote:
> > > > Indeed, they need to be reserved on the kernel side, and during the
> > > > discussion on linux-api, almost everybody seemed to be failing to
> > > > understand why this is needed... :(
> > >
> > > At least of O_SEARCH and O_EXEC I strongly disagreed with the idea that
> > > they should be implementated in userspace and still do.
> >
> > I do to, but for now it's the only way possible on Linux.
>
> The other way would be to send patches, which I tried to encourage
> you to do a few times. It basically boils down to:
>
> - allow a few more operations on O_PATH fds, as listed by Posix
> for O_SEARCH and O_EXEC
>
> - add two defines that alias O_SEARCH and O_EXEC to (O_PATH|3),
> and..
>
> > For instance
> > it seems to be impossible to implement the POSIX rule (at least as I
> > understand it) that, when using an O_SEARCH or O_EXEC fd, the status
> > of the +x mode bit at open-time, rather than at the time of the
> > operation, dictates success or failure. There are a few other corner
> > cases where you want O_PATH and O_SEARCH/O_EXEC to behave differently,
> > too: for example, O_PATH|O_NOFOLLOW should open the symlink, while
> > O_SEARCH|O_NOFOLLOW or O_EXEC|O_NOFOLLOW should fail if the target is
> > a symlink.
>
> implement these quirks keyed off the (O_PATH|3) flag.
The symlink thing is easy to do, but the permissions thing is hard.
O_PATH does not open the actual file at all, just a reference to the
inode. It would be easy to just reject the open request if +x
permission is not available at open time, but the hard part is making
the +x permission stick at open time in the case where it's removed
from the underlying file after the open takes place. It would take
help from someone who knows the kernel internals a lot better than me
to make this work.
My thought is that O_SEARCH and O_EXEC should probably be defined as
3|O_PATH, but _not_ treated as O_PATH on the kernel side. Instead,
having the O_PATH bit set on top of the "secret" access mode 3 should
behave more like normal access mode 3, but with the usual permission
checks bypassed and replaced by checks for +x, and this +x access
right should be kept with the open file description. The reason for
using 3|O_PATH then is not to get O_PATH semantics, but for a graceful
fallback on older kernels that lack real O_SEARCH/O_EXEC support:
O_PATH is a reasonably close emulation, and old kernels will ignore
the access mode bits (3) when O_PATH is set.
Rich