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: Sun, 5 Oct 2014 12:13:58 -0400
- Subject: Re: C11 threads ABI questions - enum values
- Authentication-results: sourceware.org; auth=none
- References: <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> <20141004225756 dot GV23797 at brightrain dot aerifal dot cx> <20141005094913 dot GA7947 at lst dot de>
On Sun, Oct 05, 2014 at 11:49:13AM +0200, Christoph Hellwig wrote:
> On Sat, Oct 04, 2014 at 06:57:56PM -0400, Rich Felker wrote:
> > 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.
>
> The kernel uses FMODE_* flags on file->f_mode for that. There are
> is no FMODE_EXEC right now, but it can be added along the lines of
> FMODE_READ/FMODE_WRITE trivially. If you need more detailed help
> feel free to contact me off list.
OK I'll look at it.
> > 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.
>
> Well, O_SEARCH and O_EXEC is very similar to O_PATH, so I would
> treat it conceptually the same, that is make fdget fail on file
> descriptors opened on it, and thus make all the normal operations
> impossible with a high level exclusion. It would suggest to initially
> allow the additional operations like chown for all O_PATH descriptors.
Yes, the lack of support for fchown, fchmod, fstat, fstatfs, fchdir,
and perhaps others on O_PATH file descriptors is another problem with
using O_PATH outright. In musl I have fallback support that uses
/proc/self/fd/%d for these operations when the initial syscall fails
with EBADF despite being a valid file descriptor, but it would be nice
if the kernel just supported them directly. Is it reasonably easy to
add support for O_PATH file descriptors on the kernel side? If not,
that would be an indication that O_EXEC/O_SEARCH should perhaps not
work like O_PATH but "actually open the file".
Rich