Re: File descriptors inherited by restore_command - Mailing list pgsql-hackers

From Tom Lane
Subject Re: File descriptors inherited by restore_command
Date
Msg-id 30478.1561126991@sss.pgh.pa.us
Whole thread Raw
In response to Re: File descriptors inherited by restore_command  (David Steele <david@pgmasters.net>)
Responses Re: File descriptors inherited by restore_command
Re: File descriptors inherited by restore_command
List pgsql-hackers
David Steele <david@pgmasters.net> writes:
> On 6/21/19 9:45 AM, Tom Lane wrote:
>> +1 for using O_CLOEXEC on machines that have it.  I don't think I want to
>> jump through hoops for machines that don't have it --- POSIX has required
>> it for some time, so there should be few machines in that category.

> 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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: File descriptors inherited by restore_command
Next
From: Tom Lane
Date:
Subject: Re: File descriptors inherited by restore_command