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

[James Y Knight]

On Jun 24, 2007, at 2:19 PM, Martin v. Löwis wrote:
> I don't see why it is a requirement to *open* the file in
> non-inheritable mode. Why is not sufficient to *modify*
> an open file to have its handle non-inheritable in
> an easy and platform-independent way?

Threads. Consider that you may fork a process on one thread right  
between the calls to open() and fcntl(F_SETFD, FD_CLOEXEC) on another  
thread. The only way to be safe is to open the file non-inheritable  
to start with.

Now, it is currently impossible under linux to open a file descriptor  
noninheritable, but they're considering adding that feature (I don't  
have the thread-refs on me, but it's actually from the last month).  
The issue is that there's a *bunch* of syscalls that open FDs: this  
feature would need to be added to all of them, not only "open".

It's possible that it makes sense for python to provide "as good as  
possible" an implementation. At the least, putting the fcntl call in  
the same C function as open would fix programs that don't open files/ 
spawn processes outside of the GIL protection.

But, like the kernel, this feature then ought to be provided for all  
APIs that create file descriptors.

>>> With that API, it would be possible to provide cross-platform
>>> access to the close-on-exec flag. Applications interested in setting
>>> it could then set it right after opening the file.
>>
>> YES - that's exactly why I proposed an open_noinherit function.
>
> I think I missed that proposal. What would that function do?
>
> If you propose it to be similar to the open() function, I'd
> be skeptical. It's not possible to implement that in thread-safe
> way if you use SetHandleInformation/ioctl.

Now I'm confused: are you talking about the same thread-safety  
situation as I described above? If so, why did you ask why it's not  
sufficient to modify a handle to be non-inheritable?

James