Thread: listening addresses
[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@dunslane.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@dunslane.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@dunslane.net> writes:
> Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.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
Andrew, Tom:
This will be a really nice feature for those of us with PG servers that
participate in VPNs. Currently I'm blocking certain interfaces using
pg_hba.conf but would prefer a "listen" address instead.
Of course, the drawback to this is that confused DBAs will have their
pg_hba.conf conflict with their postgresql.conf, and cut off all access to
the DB. But I don't know how we can protect against that.
Might I suggest that this default to "127.0.0.1" in postgresql.conf.sample?
This is a reasonably safe default, and would allow us to use the same default
for Windows as for other OSes. It would also eliminate about 15% of the
questions I get on a weekly basis from PHP users. ("uncomment the line
tcpip_sockets ...").
If I had time, I would also love to see setting the password for the postgres
user become part of the initdb script. However, I can see that this wouldn't
work with packages.
--
Josh Berkus
Aglio Database Solutions
San Francisco
Josh Berkus wrote:
> Andrew, Tom:
>
> This will be a really nice feature for those of us with PG servers that
> participate in VPNs. Currently I'm blocking certain interfaces using
> pg_hba.conf but would prefer a "listen" address instead.
>
> Of course, the drawback to this is that confused DBAs will have their
> pg_hba.conf conflict with their postgresql.conf, and cut off all access to
> the DB. But I don't know how we can protect against that.
>
> Might I suggest that this default to "127.0.0.1" in postgresql.conf.sample?
> This is a reasonably safe default, and would allow us to use the same default
> for Windows as for other OSes. It would also eliminate about 15% of the
> questions I get on a weekly basis from PHP users. ("uncomment the line
> tcpip_sockets ...").
>
> If I had time, I would also love to see setting the password for the postgres
> user become part of the initdb script. However, I can see that this wouldn't
> work with packages.
Why couldn't we do something where we ask for a password only if stdin
is from a terminal?
-- 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,
Pennsylvania19073
Josh Berkus <josh@agliodbs.com> writes:
> Might I suggest that this default to "127.0.0.1" in postgresql.conf.sample?
No, the default should be "localhost". Your thinking is too
IPv4-centric.
regards, tom lane
Tom, > No, the default should be "localhost". Your thinking is too > IPv4-centric. Good point. My clients are all years away from implementing Ipv6, so I tend to forget about it. -- -Josh BerkusAglio Database SolutionsSan Francisco
Josh Berkus wrote:
>Andrew, Tom:
>
>This will be a really nice feature for those of us with PG servers that
>participate in VPNs. Currently I'm blocking certain interfaces using
>pg_hba.conf but would prefer a "listen" address instead.
>
>
You can configure listening addresses now using the virtual_host GUC
setting. The documentation was execrable, but Tom has fixed that.
>Of course, the drawback to this is that confused DBAs will have their
>pg_hba.conf conflict with their postgresql.conf, and cut off all access to
>the DB. But I don't know how we can protect against that.
>
>
That surely can't be more than are seen now on IRC who can't contact
their DBs because they forgot to turn on tcpip. Plus this does not
intefere at all with Unix sockets, so they should still be able to use
the local psql (except on Windows, where you have to use tcpip sockets).
I am betting that 95%+ of users will either use the default (no remote
connections) or "*" (bind to all interfaces).
>Might I suggest that this default to "127.0.0.1" in postgresql.conf.sample?
>This is a reasonably safe default, and would allow us to use the same default
>for Windows as for other OSes. It would also eliminate about 15% of the
>questions I get on a weekly basis from PHP users. ("uncomment the line
>tcpip_sockets ...").
>
>
>
The intention is to make "localhost" the default. That should translate
to 127.0.0.1 and ::1 (if they have ipv6 on). Of course, if they have a
broken resolver things might get sticky, but that is true now anyway.
>If I had time, I would also love to see setting the password for the postgres
>user become part of the initdb script. However, I can see that this wouldn't
>work with packages.
>
>
>
Orthogonal problem.
cheers
andrew
I wrote: > Josh Berkus wrote: > >> If I had time, I would also love to see setting the password for the >> postgres user become part of the initdb script. However, I can see >> that this wouldn't work with packages. >> >> >> > > Orthogonal problem. > BTW, initdb is no longer a script - some idiot rewrote it in C :-) And it does have a switch for setting the superuser password: -W --pwprompt Makes initdb prompt for a password to give the database superuser. If you don't plan on using password authentication,this is not important. Otherwise you won't be able to use password authentication until you have a passwordset up. cheers andrew
Idiot is such a strong word, don't you think? -----Original Message----- From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Andrew Dunstan Sent: Tuesday, March 16, 2004 7:26 AM To: Postgresql Hackers Subject: Re: [HACKERS] listening addresses I wrote: > Josh Berkus wrote: > >> If I had time, I would also love to see setting the password for the >> postgres user become part of the initdb script. However, I can see >> that this wouldn't work with packages. >> >> >> > > Orthogonal problem. > BTW, initdb is no longer a script - some idiot rewrote it in C :-) And it does have a switch for setting the superuser password: -W --pwprompt Makes initdb prompt for a password to give the database superuser. If you don't plan on using password authentication,this is not important. Otherwise you won't be able to use password authentication until you have a passwordset up. cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Andrew Dunstan <andrew@dunslane.net> writes:
> The intention is to make "localhost" the default. That should translate
> to 127.0.0.1 and ::1 (if they have ipv6 on). Of course, if they have a
> broken resolver things might get sticky, but that is true now anyway.
Just to be clear: right now, if "localhost" doesn't resolve then the
stats collector will not start, but this doesn't prevent use of the
database. It might be a good idea to ensure that the same is still true
after making this change; that is, invalid entries in listen_addresses
should only provoke warnings and not refusal to start (assuming that
we are able to find at least one valid socket to listen to, of course).
I believe that right now, any bad entry in virtual_host causes the
postmaster to error out. That's defensible from one point of view but
on balance I think it's overly paranoid. Any other opinions out there?
regards, tom lane
John Hansen wrote: >Idiot is such a strong word, don't you think? > > > you should hear what my enemies call me .... cheers andrew
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>The intention is to make "localhost" the default. That should translate >>to 127.0.0.1 and ::1 (if they have ipv6 on). Of course, if they have a >>broken resolver things might get sticky, but that is true now anyway. >> >> > >Just to be clear: right now, if "localhost" doesn't resolve then the >stats collector will not start, but this doesn't prevent use of the >database. It might be a good idea to ensure that the same is still true >after making this change; that is, invalid entries in listen_addresses >should only provoke warnings and not refusal to start (assuming that >we are able to find at least one valid socket to listen to, of course). >I believe that right now, any bad entry in virtual_host causes the >postmaster to error out. That's defensible from one point of view but >on balance I think it's overly paranoid. Any other opinions out there? > > > Makes sense - we are not giving anything away but *not* listening to something. I did wonder if we should treate "localhost" as a bit special and not rely on the resolver for it. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> I did wonder if we should treate "localhost" as a bit special and not
> rely on the resolver for it.
I don't think so; we went in the other direction in 7.4 for pgstats.
(It used to try to bind to "127.0.0.1" and now tries "localhost".)
So far I've not seen any evidence that makes me think that was a bad
choice.
regards, tom lane
Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: > > Might I suggest that this default to "127.0.0.1" in postgresql.conf.sample? > > No, the default should be "localhost". Your thinking is too > IPv4-centric. FYI, once we default to listening on localhost, we need to warn folks who are using socket permission to control access that they have to turn off localhost. That needs to be mentioned in the release notes, and in the SGML docs that talk about socket permissions. -- 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> FYI, once we default to listening on localhost, we need to warn folks
> who are using socket permission to control access that they have to turn
> off localhost. That needs to be mentioned in the release notes, and in
> the SGML docs that talk about socket permissions.
True. I don't see this as a big problem, since use of socket
permissions requires some nondefault settings in postgresql.conf
anyway (IIRC). Adjusting listen_addresses too shouldn't be a big
deal.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > FYI, once we default to listening on localhost, we need to warn folks > > who are using socket permission to control access that they have to turn > > off localhost. That needs to be mentioned in the release notes, and in > > the SGML docs that talk about socket permissions. > > True. I don't see this as a big problem, since use of socket > permissions requires some nondefault settings in postgresql.conf > anyway (IIRC). Adjusting listen_addresses too shouldn't be a big > deal. No, it isn't a problem. I just wanted to mention is so we remember to address it. -- 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, Pennsylvania19073
Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>I did wonder if we should treate "localhost" as a bit special and not
>>rely on the resolver for it.
>>
>>
>
>I don't think so; we went in the other direction in 7.4 for pgstats.
>(It used to try to bind to "127.0.0.1" and now tries "localhost".)
>So far I've not seen any evidence that makes me think that was a bad
>choice.
>
>
>
A small problem with it was reported to me a couple of days ago - user
had firewalled off all IP6 traffic. The stats collector happily bound
and connected to the socket, but all the packets fell in the bit bucket.
They found it quite hard to diagnose the problem.
Possible solutions that occurred to me:
. an initial "hello"-"yes i'm here" exchange to validate the address
. a configurable stats collector address
. fix the firewall ("Doctor, it hurts when I move like this." - "So,
stop moving like that.")
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> A small problem with it was reported to me a couple of days ago - user
> had firewalled off all IP6 traffic. The stats collector happily bound
> and connected to the socket, but all the packets fell in the bit bucket.
> They found it quite hard to diagnose the problem.
> Possible solutions that occurred to me:
> . an initial "hello"-"yes i'm here" exchange to validate the address
That one seems reasonable to me. Seems like it would take just a few
more lines of code in the loop that tries to find a working socket to
check that we can send a byte and receive it. You'd have to be careful
not to block if the socket is indeed not working ... also, is it safe to
assume that a byte sent with send() is *immediately* ready to recv()?
regards, tom lane
Tom Lane wrote: >also, is it safe to >assume that a byte sent with send() is *immediately* ready to recv()? > > > If not presumably you could either sleep for a very small interval before the recv or select on the socket for a very small interval. Half a second should be ample, I would think. This doesn't strike me as a high priority item, but possibly worth putting on the TODO list? Or I could just include it when I get around to the rest of the listening address stuff we discussed earlier. cheers andrew