[Python-Dev] PEP 446: Open issues/questions

[Charles-François Natali]

>> 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/cf.natali%40gmail.com