[Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks

["Martin v. Löwis"]

> Yes, I have a patch implemented in pure Python.
> 
> I got the code on my workplace PC (now I am writing from home,
> that's why I said I'll post the code later).
> 
> The patch uses os.fdopen ( os.open (..., ...), ...).
> It translates IOError into OSError then to raise the same class
> of exception aso open().

Hmm. I don't think I could accept such an implementation
(whether in Python or in C). That's very hackish.

> AFAIK in the C stdlib implementation, fopen is implemented
> based on open anyway.

Sure - and in turn, open is implemented on CreateFile.
However, I don't think I would like to see an fopen
implementation in Python. Python 3 will drop stdio entirely;
for 2.x, I'd be cautious to change things because that
may break other things in an unexpected manner.

> On MS Windows, AFAIK (correct me if I am wrong), you can
> only choose either to inherit handles or not *as a whole*
> - including stdin, stdout and stderr -, when calling CreateProcess.

I'm not sure. In general, that seems to be true. However,
according to the ReactOS sources at

http://www.reactos.org/generated/doxygen/dd/dda/dll_2win32_2kernel32_2process_2create_8c-source.html#l00624

Windows will duplicate stdin,stdout,stderr from the parent
process even if bInheritHandles is false, provided that
no handles are specified in the startupinfo, and provided
that the program to be started is a console (CUI) program.

> Each handle has a security attribute that specifies whether the
> handle should be inherited or not - but this has to be specified
> when creating the handle (in the Windows CreateFile API internally).

Not necessarily. You can turn on the flag later, through
SetHandleInformation.

> Thus, on MS Windows, you can either choose to inherit all
> files opened with "open" + [stdin, stdout, stderr],
> or to not inherit any files (meaning even stdin, stdout and stderr
> will not be inherited).
> 
> In a platform-independent program, close_fds is therefore not an option.

... assuming you care about whether stdin,stdout,stderr are inherited
to GUI programs. If the child process makes no use of stdin/stdout, you
can safely set close_fds to true.

Regards,
Martin