[Python-Dev] Proposal for a new function "open_noinherit" to avoid problems with subprocesses and security risks
James Y Knight
foom at fuhm.net
Sun Jun 24 21:47:03 CEST 2007
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
More information about the Python-Dev
mailing list