On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote: > Rich Felker <dalias@xxxxxxxxxx> writes: > > > I'm not proposing code because I'm a libc developer not a kernel > > developer. I know what's needed for userspace to provide a conforming > > fexecve to applications, not how to implement that on the kernel side, > > although I'm trying to provide constructive ideas. The hostility is > > really not necessary. > > Conforming to what? > > The open group fexecve says nothing about requiring a file descriptor > passed to fexecve to have O_CLOEXEC. It doesn't require it but it allows it, and in multithreaded programs that might run child processes (or library code that might be used in such situations), O_CLOEXEC is mandatory everywhere to avoid fd leaks. > Further looking at open group specification of exec it seems to indicate > the preferred way to handle this is for the kernel to return O_NOEXEC > and then libc gets to figure out how to run the shell script. Is that > the kind of ``conforming'' implementation you are looking for? This is a complex issue, and does not apply to native #! support (which is a supported executable format and thus not ENOEXEC) but rather standard POSIX shell scripts (which don't have a #! line at all). In this case the behavior of fexecve is perhaps under-specified. However, in cases where execve would succeed (without causing ENOEXEC), I think it's at least undesirable, if not non-conforming, for fexecve to fail. Should we request clarification from the Austin Group? Rich -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
