On Fri, Jan 11, 2013 at 5:30 PM, Charles-François Natali < cf.nat...@gmail.com> wrote:
> > 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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
