Should libpq set close-on-exec flag on its socket?

Started by Tom Laneabout 21 years ago5 messages
#1Tom Lane
Tom Lane
tgl@sss.pgh.pa.us

It was suggested to me off-list that libpq should do
"fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server.
This would prevent any child program from accidentally or maliciously
interfering with the connection. It would also prevent people from
deliberately turning over a connection to a child; I'm not sure that
that's useful, but I'm not sure it's useless either.

Comments, opinions?

regards, tom lane

#2Dennis Bjorklund
Dennis Bjorklund
db@zigo.dhs.org
In reply to: Tom Lane (#1)
Re: Should libpq set close-on-exec flag on its socket?

On Thu, 21 Oct 2004, Tom Lane wrote:

It was suggested to me off-list that libpq should do
"fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server.
This would prevent any child program from accidentally or maliciously
interfering with the connection.

Either way that the lib sets it, the client can alter the setting itself
by issuing a new SETFD command. I would not have expected it to be set
but it is probably a good idea for most clients (and for most file
descriptors).

--
/Dennis Björklund

#3Tom Lane
Tom Lane
tgl@sss.pgh.pa.us
In reply to: Dennis Bjorklund (#2)
Re: Should libpq set close-on-exec flag on its socket?

Dennis Bjorklund <db@zigo.dhs.org> writes:

On Thu, 21 Oct 2004, Tom Lane wrote:

It was suggested to me off-list that libpq should do
"fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server.
This would prevent any child program from accidentally or maliciously
interfering with the connection.

Either way that the lib sets it, the client can alter the setting itself
by issuing a new SETFD command.

That's a fair point, and certainly passing it down to the child
intentionally wouldn't be a common case. I'll put the change in.

regards, tom lane

#4Kevin Brown
Kevin Brown
kevin@sysexperts.com
In reply to: Tom Lane (#3)
Re: Should libpq set close-on-exec flag on its socket?

Tom Lane wrote:

Dennis Bjorklund <db@zigo.dhs.org> writes:

On Thu, 21 Oct 2004, Tom Lane wrote:

It was suggested to me off-list that libpq should do
"fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server.
This would prevent any child program from accidentally or maliciously
interfering with the connection.

Either way that the lib sets it, the client can alter the setting itself
by issuing a new SETFD command.

That's a fair point, and certainly passing it down to the child
intentionally wouldn't be a common case. I'll put the change in.

Since program authors who would care about this one way or another
probably won't be expecting this behavior, it should also be
documented reasonably well -- something which I'm rather sure you were
going to do anyway.

--
Kevin Brown kevin@sysexperts.com

#5Noname
Noname
dom@happygiraffe.net
In reply to: Tom Lane (#1)
Re: Should libpq set close-on-exec flag on its socket?

On Thu, Oct 21, 2004 at 02:10:48PM -0400, Tom Lane wrote:

It was suggested to me off-list that libpq should do
"fcntl(fd, F_SETFD, FD_CLOEXEC)" on the socket connecting to the server.
This would prevent any child program from accidentally or maliciously
interfering with the connection. It would also prevent people from
deliberately turning over a connection to a child; I'm not sure that
that's useful, but I'm not sure it's useless either.

Comments, opinions?

This is a very good idea. We've had problems with Perl programs that
call other scripts (over an exec boundary) and end up with unnecessary
DBD::Pg file handles hanging around. This would be good to prevent
that.

-Dom