On Tue, Aug 06, 2013 at 05:54:15PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 06, 2013 at 11:23:16AM -0400, Rich Felker wrote:
> > > For that we'd also want to move fexec(ve) into the kernel space.
> >
> > I agree this would be useful, but it's a separate issue.
>
> I don't think it is. The whole point of O_EXEC is to support fexecve.
>
> Without moving it to kernel I can't see how you can make it strictly
> conforming to this requirement in Posix that the file descriptor
> must be valid for executing.
POSIX is contradictory on this issue. I should probably file a request
for an interpretation. On the one hand, fexecve "shall fail" if:
"The fd argument is not a valid file descriptor open for executing."
On the other hand, the application usage text (non-normative, if I'm
not mistaken) reads:
"Since execute permission is checked by fexecve(), the file
description fd need not have been opened with the O_EXEC flag.
However, if the file to be executed denies read and write permission
for the process preparing to do the exec, the only way to provide
the fd to fexecve() will be to use the O_EXEC flag when opening fd.
In this case, the application will not be able to perform a checksum
test since it will not be able to read the contents of the file."
This suggests that file descriptors opened in other modes could be
used, and that O_EXEC only exists so that you can open a file you
would otherwise not have permissions to. Moreover, early in the
normative ("description") text, it reads:
"The fexecve() function shall be equivalent to the execve() function
except that the file to be executed is determined by the file
descriptor fd instead of a pathname. The file offset of fd is
ignored."
Anyway, if failure when O_ACCMODE is not O_EXEC is required, it's
trivial to do in userspace: just call fcntl(F_GETFL) on the file
descriptor and generate an artificial EBADF if O_PATH is not set.
(Naturally this check would be omitted on pre-O_PATH kernels where
full conformance is not possible.)
Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
