>> Having stdin/stdout/stderr cloexec (e.g. after a dup() to redirect to >> a log file, a socket...) will likely break a lot of code, e.g. code >> using os.system(), or code calling exec manually (and I'm sure there's >> a bunch of it). > > Hmm. os.exec*() could easily make standard streams non-CLOEXEC before > calling the underlying C library function. Things are more annoying for > os.system(), though. > >> Also, it'll be puzzling to have syscalls automatically set the cloexec >> flag. I guess a lot of people doing system programming with Python >> will get bitten, but that's a discussion we already had months ago... > > Perhaps this advocates for a global flag, e.g. > sys.set_default_fd_inheritance(), with False (non-inheritable) being > the default for sanity and security.
This looks more and more like PEP 433 :-) And honestly, when I think about it, I think that this whole mess is a solution looking for a problem. If we don't want to inherit file descriptors in child processes, the answer is simple: the subprocess module (this fact is not even mentioned in the PEP). If a user wants to use the execve() syscall directly, then he should be aware of the implications. I don't think that patching half the stdlib and complicating the API of many functions is the right way to do this. The stdlib should be updated to replace the handful of places where exec() is called explicitly by subprocess (the only one I can think on top of my head is http.server.CGIHTTPRequestHandler (issue #16945)), otherwise that's about it. cf > > Regards > > Antoine. > > > _______________________________________________ > 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/cf.natali%40gmail.com _______________________________________________ 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