Re: File descriptors inherited by restore_command

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
david(at)pgmasters(dot)net