Rich Felker [off-list ref] 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.
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?
Eric
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
Rich Felker [off-list ref] writes:
quoted
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
On Sat, Jan 10, 2015 at 1:33 AM, Rich Felker [off-list ref] wrote:
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
quoted
Rich Felker [off-list ref] writes:
quoted
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.
As a naive idea related to Andy's suggestion elsewhere, could you
just have an environment convention for fexecve-ing scripts? That
would reduce FD leaks without any need for kernel involvement/changes.
For example, set _FEXECVED_VIA_FD=4 but don't set
O_CLOEXEC before fexecve, and the interpreter reads then
closes that FD. Or just get the interpreter to spot scripts named
"/dev/fd/%d" and read-then-close the FD that way, cf. Eric's suggestion
at https://lkml.org/lkml/2014/10/22/652.
By the way, FreeBSD has a fexecve(2) syscall that behaves
in the same way as the current Linux code for an O_CLOEXEC
script -- the interpreter fails to open "/dev/fd/6" as it's gone.
Do you know if there are any other OSes that already do
something more sophisticated for this case?
On Mon, Jan 12, 2015 at 11:33:49AM +0000, David Drysdale wrote:
On Sat, Jan 10, 2015 at 1:33 AM, Rich Felker [off-list ref] wrote:
quoted
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
quoted
Rich Felker [off-list ref] writes:
quoted
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.
As a naive idea related to Andy's suggestion elsewhere, could you
just have an environment convention for fexecve-ing scripts? That
would reduce FD leaks without any need for kernel involvement/changes.
For example, set _FEXECVED_VIA_FD=4 but don't set
O_CLOEXEC before fexecve, and the interpreter reads then
closes that FD. Or just get the interpreter to spot scripts named
"/dev/fd/%d" and read-then-close the FD that way, cf. Eric's suggestion
at https://lkml.org/lkml/2014/10/22/652.
No. Any omission of O_CLOEXEC even momentarily is a potentially
dangerous fd leak. This is the case whenever the process is
multithreaded and it's possible that other threads might fork and
exec. Think of the case of a privileged daemon re-execing itself (e.g.
to switch to an updated version) while there are potentially other
threads spawning non-privileged processes.
Rich