[Python-Dev] PEP 433: Add cloexec argument to functions creating file descriptors

[Nick Coghlan]

On Mon, Jan 14, 2013 at 8:06 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>>
>> Agreed, but it's the security implications that let us even
>> contemplate the backwards compatibility break.
>
>
> I don't think that's a sufficient criterion for choosing a
> name. The backwards compatibility issue is a transitional
> thing, but we'll be stuck with the name forever.
>
> IMO the name should simply describe the mechanism, and be
> neutral as to what the reason might be for using the
> mechanism.

The problem is the mechanism is *not the same* on Windows and POSIX -
the Windows mechanism (noinherit) means the file won't be accessible
in child processes, the POSIX mechanism (cloexec) means it won't
survive exec(). This difference really shows up with multiprocessing,
as that uses a bare fork() without exec() on POSIX systems, meaning
even flagged descriptors will still be inherited by the child
processes.

A flag like "sensitive" or "protected" or "private" tells the
interpreter "keep this to yourself, as best you can", leaving Python
implementors with a certain amount of freedom in the way they
translate that into platform appropriate settings (e.g. does "cloexec"
or "noinherit" even make sense in Java?)

I agree with Glenn's point that "sensitive" in particular is a bad
choice, but a more value neutral term like "protect" may still work.
We can then explain what it means to protect a file descriptor on the
various platforms, and potentially even change the meaning over time
as the platforms provide additional capabilities.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia