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

[Guido van Rossum]

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)