Обсуждение: Re: [HACKERS] Another crack at doing a Win32 build under MINGW
> > I've seen both these messages after each other when -i is not > > specified. Been meaning to adress the issue of it not failing > > gracefully without -i on win32. > > > > Anyway. It seems the postmaster goes down while a child process is > > still going up (stats collector, I guess) or something along that > > line. This way the child can't attach to shared memory, and > there you > > go. > > > > If you add PID information to the log, you will notice that the > > messages are from two different processes. > > > > Is there a case for forcing -i and ignoring the GUC setting > on Windows? Since we can't do Unix domain sockets there it > would seem to make sense. Yeah, that could be done. I was more into doing a generic fix that would fail gracefully in any case when the server is not listening on anything (no Unix, no TCPIP) and error out then. Are there any other platforms which don't have unix sockets? If not, then that thought is not valid, and we shuold just force it on win32. If not, how do they handle starting of the postmaster without -i today? And do we want the same behaviour there? Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That way we don't suddenly open up to external connections without the user asking for it. //Magnus
Magnus Hagander said: >> > I've seen both these messages after each other when -i is not >> > specified. Been meaning to adress the issue of it not failing >> > gracefully without -i on win32. >> > >> > Anyway. It seems the postmaster goes down while a child process is >> > still going up (stats collector, I guess) or something along that >> > line. This way the child can't attach to shared memory, and >> there you >> > go. >> > >> > If you add PID information to the log, you will notice that the >> > messages are from two different processes. >> > >> >> Is there a case for forcing -i and ignoring the GUC setting >> on Windows? Since we can't do Unix domain sockets there it >> would seem to make sense. > > Yeah, that could be done. I was more into doing a generic fix that > would fail gracefully in any case when the server is not listening on > anything (no Unix, no TCPIP) and error out then. > > Are there any other platforms which don't have unix sockets? If not, > then that thought is not valid, and we shuold just force it on win32. > If not, how do they handle starting of the postmaster without -i today? > And do we want the same behaviour there? > > Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That > way we don't suddenly open up to external connections without the user > asking for it. > Hmm. That also raises the question of what we should do if virtual_host is set. [thinks some more ...] cheers andrew
I wrote: >Magnus Hagander said: > > >>>Is there a case for forcing -i and ignoring the GUC setting >>>on Windows? Since we can't do Unix domain sockets there it >>>would seem to make sense. >>> >>> >>Yeah, that could be done. I was more into doing a generic fix that >>would fail gracefully in any case when the server is not listening on >>anything (no Unix, no TCPIP) and error out then. >> >>Are there any other platforms which don't have unix sockets? If not, >>then that thought is not valid, and we shuold just force it on win32. >>If not, how do they handle starting of the postmaster without -i today? >>And do we want the same behaviour there? >> >>Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That >>way we don't suddenly open up to external connections without the user >>asking for it. >> >> >> > >Hmm. That also raises the question of what we should do if virtual_host is >set. > >[thinks some more ...] > > > ..... How does this sound? . if -i/tcpip_socket is not set, then bind to localhost . if -i/tcpip_socket is set, and virtual_host is not set, behave as now (i.e. bind to all addresses) . if -i/tcpip_socket is set, and virtual_host is set, bind to all but immediately close connections where the local address is not either localhost or the virtual_host. That seems to me to get as close as reasonably possible to the Unix behaviour. I don't think that always allowing localhost connections on Windows is a big security risk. Also, what is the default connection mode of psql? It should probably be equivalent to "-h localhost", shouldn't it? I haven't thought through what might be the IP4/IP6 implications. cheers andrew
"Magnus Hagander" <mha@sollentuna.net> writes:
> Are there any other platforms which don't have unix sockets?
There are a couple, although I think those ports may be moribund
(if anyone still cares about BeOS, they haven't mentioned it lately).
> Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That
> way we don't suddenly open up to external connections without the user
> asking for it.
That seems like a reasonable compromise.
regards, tom lane
Tom Lane wrote: > "Magnus Hagander" <mha@sollentuna.net> writes: > > Are there any other platforms which don't have unix sockets? > > There are a couple, although I think those ports may be moribund > (if anyone still cares about BeOS, they haven't mentioned it lately). > > > Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That > > way we don't suddenly open up to external connections without the user > > asking for it. > > That seems like a reasonable compromise. Agreed, but how do we do that. pg_hba.conf already only listens on 127.0.0.1. Do we ignore non-local IPs in that file until they use -i? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: >Tom Lane wrote: > > >>"Magnus Hagander" <mha@sollentuna.net> writes: >> >> >>>Are there any other platforms which don't have unix sockets? >>> >>> >>There are a couple, although I think those ports may be moribund >>(if anyone still cares about BeOS, they haven't mentioned it lately). >> >> >> >>>Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That >>>way we don't suddenly open up to external connections without the user >>>asking for it. >>> >>> >>That seems like a reasonable compromise. >> >> > >Agreed, but how do we do that. pg_hba.conf already only listens on >127.0.0.1. Do we ignore non-local IPs in that file until they use -i? > > > Those are remote addresses, not local addresses. pg_hba.conf doesn't say anything at all about the listening address. The errors that have been reported would have passed the default pg_hba.conf filters - the problem as I understand it was that there was no listener on the localhost interface. It is true, though,. that you can't (or shouldn't) be able to connect to localhost except from localhost. cheers andrew
Andrew Dunstan wrote: > How does this sound? > > . if -i/tcpip_socket is not set, then bind to localhost > . if -i/tcpip_socket is set, and virtual_host is not set, behave as now > (i.e. bind to all addresses) > . if -i/tcpip_socket is set, and virtual_host is set, bind to all but > immediately close connections where the local address is not either > localhost or the virtual_host. > > That seems to me to get as close as reasonably possible to the Unix > behaviour. I don't think that always allowing localhost connections on > Windows is a big security risk. > > Also, what is the default connection mode of psql? It should probably be > equivalent to "-h localhost", shouldn't it? Now that is something I had not thought of. Seems we can assume a Win32 psql can never use unix domain sockets, so defaulting that to localhost is a good solution too. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> Andrew Dunstan wrote:
>> That seems to me to get as close as reasonably possible to the Unix
>> behaviour. I don't think that always allowing localhost connections on
>> Windows is a big security risk.
Is it a big security risk anywhere? Perhaps there is a case to be made
that on all platforms, "-i" should enable or disable only nonlocal
connections. Without -i we'd only allow binding to loopback ports
(either IP4 or IP6).
Aside from keeping the Windows and Unix behaviors similar, this would be
of some positive benefit for people who use TCP-only clients. They'd
not have to remember to set -i anymore, unless they want remote access.
In response to Andrew's table, here's what I'm visualizing:
* No -i: bind only to loopback addresses (both IP4 and IP6 if available).
* With -i, but not virtual_host: bind to all available addresses.
* With -i and virtual_host: bind to specified address(es) only.
(Note this is orthogonal to pg_hba.conf checks; we are talking about
what socket addresses the postmaster listens on.)
I don't have a strong feeling about the case of virtual_host without -i.
The above says to ignore virtual_host, but maybe we should instead
ignore the lack of -i and do what virtual_host says.
regards, tom lane
Tom Lane wrote: >Perhaps there is a case to be made >that on all platforms, "-i" should enable or disable only nonlocal >connections. Without -i we'd only allow binding to loopback ports >(either IP4 or IP6). > >Aside from keeping the Windows and Unix behaviors similar, this would be >of some positive benefit for people who use TCP-only clients. They'd >not have to remember to set -i anymore, unless they want remote access. > > I've been caught by this more than once, because I use local JDBC clients, so now the first thing I do after initdb is to set tcpip_socket to true. >In response to Andrew's table, here's what I'm visualizing: > >* No -i: bind only to loopback addresses (both IP4 and IP6 if available). > > OK. >* With -i, but not virtual_host: bind to all available addresses. > > OK. >* With -i and virtual_host: bind to specified address(es) only. > > Can you bind one socket to more than one address? My understanding is that it's all (IN_ADDR_ANY or in6_addr_any) or one. In that case with this proposal we'd have to force all the communications through that interface on Windows. Or would we use multiple sockets (in which case there is probably a good case for allowing multiple addresses in virtual_host)? ... (haven't toured this part of the code before) .... I see what looks like an array of listen sockets, so multiple sockets seems the way to go. > >I don't have a strong feeling about the case of virtual_host without -i. >The above says to ignore virtual_host, but maybe we should instead >ignore the lack of -i and do what virtual_host says. > > > I have no strong feelings either. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> * With -i and virtual_host: bind to specified address(es) only.
> Can you bind one socket to more than one address?
Nope. That's why we have provisions to listen on more than one socket.
I think that was implemented for virtual_host, but it'd be necessary
anyway for dual IPv4/IPv6 support.
regards, tom lane
Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>* With -i and virtual_host: bind to specified address(es) only.
>>>
>>>
>
>
>
>>Can you bind one socket to more than one address?
>>
>>
>
>Nope. That's why we have provisions to listen on more than one socket.
>I think that was implemented for virtual_host, but it'd be necessary
>anyway for dual IPv4/IPv6 support.
>
>
>
I should have read the code instead of the docs, which only talk about
one address under virtual_host, not a space separated list of them:
virtual_host (string)
Specifies the host name or IP address on which the server is to
listen for connections from client applications. The default is to
listen on all configured addresses (including localhost).
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> I should have read the code instead of the docs, which only talk about
> one address under virtual_host, not a space separated list of them:
That's pretty bogus. I've committed improved wording.
regards, tom lane