On 6/21/19 10:26 AM, Stephen Frost wrote: >> >>> Another possible issue is that if we allow a child process to inherit >>> all these fds it might accidentally write to them, which would be bad. >>> I know the child process can go and maliciously open and trash files if >>> it wants, but it doesn't seem like we should allow it to happen >>> unintentionally. >> >> True. But I don't want to think of this as a security issue, because >> then it becomes a security bug to forget O_CLOEXEC anywhere in the >> backend, and that is a standard we cannot meet. (Even if we could >> hold to it for the core code, stuff like libperl and libpython can't >> be relied on to play ball.) In practice, as long as we use O_CLOEXEC >> for files opened by fd.c, that would eliminate the actual too-many-fds >> hazard. I don't object to desultorily looking around for other places >> where we might want to add it, but personally I'd be satisfied with a >> patch that CLOEXEC-ifies fd.c. > > Agreed, it's not a security issue, and also agreed that we should > probably get it done with fd.c right off, and then if someone wants to > think about other places where it might be good to do then more power to > them and it seems like we'd be happy to accept such patches.
I agree this is not a security issue and I wasn't intending to present it that way, but in general the more fds closed the better. I'll work up a patch for fd.c which is the obvious win and we can work from there if it makes sense. I'll be sure to test EXEC_BACKEND on Linux but I don't think it will matter on Windows. cfbot may feel differently, though. Regards, -- -David da...@pgmasters.net
signature.asc
Description: OpenPGP digital signature
