> That could always be overcome by passing close_fds=False explicitly to
> subprocess from my code, though, right? I'm not doing that now, but then I'm not
> using the esoteric options in python-gnupg code, either.
You could do that, or better explicitly support this option, and only
specify this file descriptor in subprocess.Popen keep_fds argument.
> My point was that the GnuPG usage looked like an example where fds other than
> 0, 1 and 2 might be used by design in not-uncommonly-used programs. From a
> discussion I had with Barry Warsaw a while ago, I seem to remember that there
> was other software which relied on these features. See [1] for details.
Yes, it might be used. But I maintain that it should be really rare,
and even if it's not, since the "official" way to launch subprocesses
is through the subprocess module, FDs > 2 are already closed by
default since Python 3.2. And the failure will be immediate and
obvious (EBADF).
I suppose I should chime in. I think the pattern of "open some file descriptors, fork,
exec" and pass the file descriptors to a child process it a very useful thing, and certainly
something I use in my code. Although to be honest, it is usually a C program doing
it.
I do this for two reason:
1) I can have a relatively small program that runs at a rather high privilege level (e.g: root),
which acquires protected resources (e.g: binds to port 80, opens some key files that only
a restricted user has access to), and then drops privileges, forks (or just execs) and passes
those resources to a larger, less trusted program.
2) I have a monitoring program that opens a socket, and then passes the socket to a child
process (via fork, exec). If that program crashes for some reason, the monitoring program
can respawn a new child and pass it the exact same socket.
Now I'm not saying these are necessarily common use cases, but I think changing the default
behaviour of file-descriptors to be close on exec would violate principle of least surprise for
anyone familiar with and expecting UNIX semantics. If you are using fork/exec directly then
I think you want these semantics. That being said, I have no problem with subprocess
closing file-descriptors before exec()-ing as I don't think a developer would necessarily
expect the UNIX semantics on that interface.
Python is not UNIX, but I think if you are directly using the POSIX interfaces they should
work (more or less) the same way the would if you were writing a C program. (Some of us
still use Python to prototype things that will later be converted to C!).
Cheers,
Benno