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: Christoph Hellwig <hch at lst dot de>
- To: Rich Felker <dalias at libc dot org>
- 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 11:49:13 +0200
- Subject: Re: C11 threads ABI questions - enum values
- Authentication-results: sourceware.org; auth=none
- References: <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> <20141004225756 dot GV23797 at brightrain dot aerifal dot cx>
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.
> 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.
There is precendence for allowing more operations on them than
initially supported, e.g. a year ago we started to allow fstatfs
on O_PATH descriptors. If a good argument against that comes up
we'll need to use the new fdget variant that only allows to grab
a reference only if FMODE_PATH isn't set or FMODE_EXEC is set,
which we will need for lookup and the new fexecve syscall anyway.