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(at)sollentuna(dot)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(at)sollentuna(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)sollentuna(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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

[removing to hackers as it is of general interest]

Tom Lane wrote:

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

This slipped off my radar. I have just spent a little while thinking
about it. How about this: we replace tcpip_socket and virtual_host with
a new var called listen_addresses, which can have values of "local",
"all", or a list of addresses? The default would be "local" and -i would
correspond to "all".

Yes, I know it's not backwards compatible, but we just went through that
argument with log_line_prefix ;-)

Actually, if we wanted to go the whole hog with virtual hosting we'd
allow per-address port specification, like apache does, but maybe that's
something to be left for another day ;-)

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> This slipped off my radar. I have just spent a little while thinking
> about it. How about this: we replace tcpip_socket and virtual_host with
> a new var called listen_addresses, which can have values of "local",
> "all", or a list of addresses? The default would be "local" and -i would
> correspond to "all".

No objection here. You could also allow "none" (or maybe that falls out
of the list case by writing an empty list), with the understanding that
"none" is a useless setting on Windows or any other platform that
doesn't support Unix sockets.

> Yes, I know it's not backwards compatible, but we just went through that
> argument with log_line_prefix ;-)

I think it's the same argument: neither of these variables are likely to
be touched by application code, only by config file entries; so we need
not feel compelled to provide backwards-compatibility options.

> Actually, if we wanted to go the whole hog with virtual hosting we'd
> allow per-address port specification, like apache does, but maybe that's
> something to be left for another day ;-)

Yeah, I don't think that's worth the trouble. It would open up a bunch
of definitional issues (like which port number do we use as the seed for
the shared memory key), without actually buying much useful functionality.

regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>This slipped off my radar. I have just spent a little while thinking
>>about it. How about this: we replace tcpip_socket and virtual_host with
>>a new var called listen_addresses, which can have values of "local",
>>"all", or a list of addresses? The default would be "local" and -i would
>>correspond to "all".
>>
>>
>
>No objection here. You could also allow "none" (or maybe that falls out
>of the list case by writing an empty list), with the understanding that
>"none" is a useless setting on Windows or any other platform that
>doesn't support Unix sockets.
>
>

I had thought about "none". I have no strong feelings either way,
althought you are right that it would be redundant.

On platforms without Unix domain sockets I think we should immediately
error exit without a valid tcp listening address.

I will try to get this done in the next few weeks - I think it's
critical for sensible Windows use.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> How about this: we replace tcpip_socket and virtual_host with
>>> a new var called listen_addresses, which can have values of "local",
>>> "all", or a list of addresses? The default would be "local" and -i would
>>> correspond to "all".
>>
>> No objection here. You could also allow "none" (or maybe that falls out
>> of the list case by writing an empty list), with the understanding that
>> "none" is a useless setting on Windows or any other platform that
>> doesn't support Unix sockets.

> I had thought about "none". I have no strong feelings either way,
> althought you are right that it would be redundant.

Also, "local" would be better spelled "localhost", which would make it
not a special case but just the same as writing a list containing just
that one name. That leaves only "all" as a special case. Perhaps you
could write "all" as "*", and thereby not have any special keywords
needed in the variable: it's either "*" or a list of addresses or names.
The advantage of this is you need not worry about collisions of DNS
names with keywords.

regards, tom lane

Bruce Momjian wrote:

>Andrew Dunstan wrote:
>
>>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.
>

The trivial patch below does this (I think). I still don't have an
available Windows box for testing, so someone who does please verify.

thanks

andrew

Index: src/bin/psql/startup.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
retrieving revision 1.85
diff -c -r1.85 startup.c
*** src/bin/psql/startup.c 19 Feb 2004 19:40:09 -0000 1.85
--- src/bin/psql/startup.c 15 Mar 2004 10:37:50 -0000
***************
*** 153,158 ****
--- 153,162 ----
pset.getPassword = false;
#endif

+ #ifndef HAVE_UNIX_SOCKETS
+ options.host = "localhost";
+ #endif
+
parse_psql_options(argc, argv, &options);

if (!pset.popt.topt.fieldSep)

Patch applied, with comment added. Thanks.

---------------------------------------------------------------------------

Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >Andrew Dunstan wrote:
> >
> >>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.
> >
>
> The trivial patch below does this (I think). I still don't have an
> available Windows box for testing, so someone who does please verify.
>
> thanks
>
> andrew
>
> Index: src/bin/psql/startup.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
> retrieving revision 1.85
> diff -c -r1.85 startup.c
> *** src/bin/psql/startup.c 19 Feb 2004 19:40:09 -0000 1.85
> --- src/bin/psql/startup.c 15 Mar 2004 10:37:50 -0000
> ***************
> *** 153,158 ****
> --- 153,162 ----
> pset.getPassword = false;
> #endif
>
> + #ifndef HAVE_UNIX_SOCKETS
> + options.host = "localhost";
> + #endif
> +
> parse_psql_options(argc, argv, &options);
>
> if (!pset.popt.topt.fieldSep)
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Should we have used 127.0.0.1 rather than 'localhost' here?

---------------------------------------------------------------------------

Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >Andrew Dunstan wrote:
> >
> >>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.
> >
>
> The trivial patch below does this (I think). I still don't have an
> available Windows box for testing, so someone who does please verify.
>
> thanks
>
> andrew
>
> Index: src/bin/psql/startup.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
> retrieving revision 1.85
> diff -c -r1.85 startup.c
> *** src/bin/psql/startup.c 19 Feb 2004 19:40:09 -0000 1.85
> --- src/bin/psql/startup.c 15 Mar 2004 10:37:50 -0000
> ***************
> *** 153,158 ****
> --- 153,162 ----
> pset.getPassword = false;
> #endif
>
> + #ifndef HAVE_UNIX_SOCKETS
> + options.host = "localhost";
> + #endif
> +
> parse_psql_options(argc, argv, &options);
>
> if (!pset.popt.topt.fieldSep)
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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 <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Should we have used 127.0.0.1 rather than 'localhost' here?

No. Think IPv6.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Should we have used 127.0.0.1 rather than 'localhost' here?
>
> No. Think IPv6.

OK, just asking in case.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073