This is the mail archive of the
mailing list for the glibc project.
Re: Request for comments: reserving a value for O_SEARCH and O_EXEC
- From: Christoph Hellwig <hch at lst dot de>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: linux-api at vger dot kernel dot org, "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Tue, 6 Aug 2013 16:51:59 +0200
- Subject: Re: Request for comments: reserving a value for O_SEARCH and O_EXEC
- References: <20130805222544 dot GA19168 at brightrain dot aerifal dot cx> <20130806055425 dot GA9280 at lst dot de> <20130806134254 dot GT221 at brightrain dot aerifal dot cx> <20130806140321 dot GA4421 at lst dot de> <20130806143609 dot GV221 at brightrain dot aerifal dot cx>
On Tue, Aug 06, 2013 at 10:36:10AM -0400, Rich Felker wrote:
> This is frustrating because early on in the O_PATH discussions on LKML
> when it was first added, there were requests for O_SEARCH and O_EXEC
> semantics in the kernel, and these requests were rejected with the
> response being roughly "you can do it in userspace using the more
> general O_PATH approach". So we have two contradictory conditions:
> - O_SEARCH/O_EXEC semantics won't be added in the kernel because you
> can do it in userspace with O_PATH.
> - O_SEARCH/O_EXEC can't be added in userspace because they can't be
> assigned a value without having an implementation in kernelspace.
> If there's a willingness to override/drop that previous decision
> (which I believe Linus was in on, but I'd have to search for the old
> threads again)
Yes, Linus has complained about it. Probably rightly so because the
O_EXEC and O_SEARCH semantics don't seem overly useful.
> then I can propose a patch. As far as I can tell, the
> simplest implementation would be to follow the O_PATH code path but
> include a check for this new mode and fail at the point of opening a
> symlink where O_NOFOLLOW is processed. I am not sufficiently familiar
> with this code to write the patch yet, but I can try to learn it. My
> guess is that the patch would be less than 20 lines, half of it being
> a change for the top-level O_PATH logic in openat that strips other
> flags when O_PATH is present and half of it being
<text missing here>
Besides the symlink semantics I think we should really get a narrow
implementation of it, that is really forbid everything but executing
it (if S_IREG()) or performing openat on it (if S_ISDIR).
For that we'd also want to move fexec(ve) into the kernel space.
> If I do this, do you have a recommendation on the value to use? My
> guess for the best choice would be O_PATH|3, so that O_PATH, O_SEARCH,
> O_EXEC, O_RDONLY, O_WRONLY, and O_RDWR can all fall under O_ACCMODE
> without adding more than one bit to O_ACCMODE. If we do it this way,
> the patch should also make it so the extra bits (bits 0 and 1) set at
> open time should be preserved when fcntl(F_GETFL) is called so that
> the application correctly sees the access mode it requested.
Note that "3" aready has a magic meaning on Linux:
"Linux reserves the special, nonstandard access mode 3 (binary 11) in flags
to mean: check for read and write permission on the file and return a
descriptor that can't be used for reading or writing. This nonstandard
access mode is used by some Linux drivers to return a descriptor that
is to be used only for device-specific ioctl(2) operations."
Given that it's limited to device nodes and a somewhat similar limitation
to O_SEARCH and O_EXEC it doesn't sound too bad.