Re: [HACKERS] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Should libpq set close-on-exec flag on its socket?
Tom Lane wrote: > Dennis Bjorklund <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Should libpq set close-on-exec flag on its socket?
Dennis Bjorklund <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Should libpq set close-on-exec flag on its socket?
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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
