[Python-Dev] PEP 433: Choose the default value of the new cloexec parameter (original) (raw)

Guido van Rossum guido at python.org
Sun Jan 27 17:24:00 CET 2013

On Sun, Jan 27, 2013 at 3:45 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On Sun, Jan 27, 2013 at 9:29 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

I don't think such limitations are very useful in practice. Users calling sys.setdefaultexec() will have to be sufficiently knowledgeable to understand the implications, anyway. I've yet to hear a use case for being able to turn it off globally if the application developer has indicated they want it on. A global flag that can be turned off programmatically is worse than no global flag at all.

Out of context that last statement sounds pretty absurd. :-)

If we're never going to migrate to cloexec-on-by-default, then there simply shouldn't be a global flag - the option should just default to False.

That doesn't seem to follow. We might never want to turn it on by default for reasons of compatibility with POSIX (whatever you say, POSIX semantics seep through Python in many places). But it might still be useful to be able to turn it on for specific programs (and doing that in code is a lot more convenient than having to say "run this app with python --cloexec", which sounds a real pain).

If we're going to migrate to cloexec-on-by-default some day, then the global flag should purely be a transition strategy to allow people to try out that future behaviour and adjust their application appropriately (by clearing the flag on descriptors that really need to be inherited). The typical default that should be assumed by library code will still be cloexec-off-by-default.

But typical library code won't care one way or another, will it?

A completely flexible global flag is just a plain bad idea for all the reasons Charles-François gave.

Honestly, what happened to the idea that we're all adults here? The likelihood that someone is clueless enough to misuse the flag and yet clueful enough to find out how to change it seems remote -- and they pretty much deserve what they get. It's like calling socket.settimeout(0.1) and then complaining that urllib.urlopen() raises exceptions, or calling sys.setrecursionlimit(1000000) when you are getting StackOverflowError.

The only reason I can see why a flag should never be changeable after the fact is when it would end up violating the integrity of the interpreter. But I don't see that here. I just see paranoia about protecting users from all possible security issues. That seems a hopeless quest.

That said, I'm sure I'll survive if you ignore my opinion, so I explicitly give you that option -- in the grand scheme of things I can't care that much about this and it seems a mostly theoretical issue. (And, an attacker who can exploit file descriptors given to it can probably find plenty of other attacks on a system they've broken into.)

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list