Re: Use "samehost" by default in pg_hba.conf?

Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:

# IPv4 local connections:
host all all 127.0.0.1/32 @authmethod@
# IPv6 local connections:
host all all ::1/128 @authmethod@

with:

# local connections via TCP/IP:
host all all samehost @authmethod@

The advantage of this is that connections made with "-h machine_name"
instead of "-h localhost" would work without customization. I can't
see any disadvantage to it. Making the change now would also give
us an opportunity to test the samehost/samenet implementation in the
buildfarm, at least for machines without Unix sockets.

(Note that you would still need a non-default setting of
listen_addresses for "-h machine_name" to actually work.)

Comments?

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
> a good idea to replace this part of the default pg_hba.conf file:
>
> # IPv4 local connections:
> host all all 127.0.0.1/32 @authmethod@
> # IPv6 local connections:
> host all all ::1/128 @authmethod@
>
> with:
>
> # local connections via TCP/IP:
> host all all samehost @authmethod@
>
> The advantage of this is that connections made with "-h machine_name"
> instead of "-h localhost" would work without customization. I can't
> see any disadvantage to it. Making the change now would also give
> us an opportunity to test the samehost/samenet implementation in the
> buildfarm, at least for machines without Unix sockets.

I'm not sure if it out-ranks the advantages of the change for buildfarm
support, but the above change isn't actually without any disadvantage.
Specifically, not every auth mechanism that works with -h machine_name
works with -h localhost, but the first record in pg_hba which is matched
is used. I could have:

host all all 127.0.0.1/32 @authmethod@
host all all A.B.C.D/32 @authmethod2@

today and a change to:

host all all samehost @authmethod@
host all all A.B.C.D/32 @authmethod2@

could override my authmethod2 and cause connections to fail, since it
isn't intended to be used. Additionally, a user could be confused if
they're familiar with 127.0.0.1/32 and not figure out why a change to
samehost is causing problems.

> (Note that you would still need a non-default setting of
> listen_addresses for "-h machine_name" to actually work.)

In any case, this is about the default pg_hba.conf and what I'm talking
about is KRB5/GSSAPI related (127.0.0.1 may not work if it resolves to
'localhost' because KRB5/GSSAPI auth is based off getting the hostname
of the machine being connected to from the reverse DNS of the IP being
connected to). As such, it's entirely possible that it's completely
irrelevant, but I wanted to bring up that 127.0.0.1->samehost could
cause issues for some folks in some configurations.

Thanks,

Stephen

On Wed, Sep 30, 2009 at 10:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The advantage of this is that connections made with "-h machine_name"
> instead of "-h localhost" would work without customization.  I can't
> see any disadvantage to it.  Making the change now would also give
> us an opportunity to test the samehost/samenet implementation in the
> buildfarm, at least for machines without Unix sockets.
>
> (Note that you would still need a non-default setting of
> listen_addresses for "-h machine_name" to actually work.)
>
> Comments?

I don't see much advantage in this proposal, at least not immediately.
If it turns out to be a wildly popular feature and doesn't turn out
to introduce security vulnerabilities or breakage, we can always make
this change later.

...Robert

On 09/30/2009 10:08 PM, Tom Lane wrote:
> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
> a good idea to replace this part of the default pg_hba.conf file:
>
> # IPv4 local connections:
> host all all 127.0.0.1/32 @authmethod@
> # IPv6 local connections:
> host all all ::1/128 @authmethod@
>
> with:
>
> # local connections via TCP/IP:
> host all all samehost @authmethod@
>
> The advantage of this is that connections made with "-h machine_name"
> instead of "-h localhost" would work without customization. I can't
> see any disadvantage to it. Making the change now would also give
> us an opportunity to test the samehost/samenet implementation in the
> buildfarm, at least for machines without Unix sockets.
>
> (Note that you would still need a non-default setting of
> listen_addresses for "-h machine_name" to actually work.)
>

Although there is probably no rush for it - I think this would be a
great "first user experience" change for PostgreSQL 8.5. If it "just
works" out of the box, this is good. In the past, my experience has been
that PostgreSQL rarely works out of the box for common scenarios. I know
some people are worried about it not working or creating some
theoretical security problem that ends up being route caused to
PostgreSQL - but I find this thinking inconsistent when I look at the
default configuration of "trust".

I would like to see the default of "trust" abolished. It scares me far
more than sameuser / samehost would ever scare me. Newbie users won't
know to fix it, and experienced users always need to fix it. I think the
default file should be something that would be most valid to most
people. For example:

local all all ident
host all all samehost md5

If this was the default, I think many installations would not require
customization, and this would be great.

Then again - maybe this will open up a huge can of worms where we debate
about which configuration is more likely for the average new user.... :-)

Anything is better than "trust" - even blocking access entirely!

Cheers,
mark

--
Mark Mielke<mark(at)mielke(dot)cc>

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> I'm not sure if it out-ranks the advantages of the change for buildfarm
> support, but the above change isn't actually without any disadvantage.
> Specifically, not every auth mechanism that works with -h machine_name
> works with -h localhost, but the first record in pg_hba which is matched
> is used. I could have:

> host all all 127.0.0.1/32 @authmethod@
> host all all A.B.C.D/32 @authmethod2@

If you've got any such thing, you've got a *nondefault* pg_hba.conf
file. Or are you opining that people who are smart enough to set
that up are too stupid to replace a single "samehost" entry with
the two entries they need?

regards, tom lane

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I don't see much advantage in this proposal, at least not immediately.
> If it turns out to be a wildly popular feature and doesn't turn out
> to introduce security vulnerabilities or breakage, we can always make
> this change later.

The advantage is to get some testing so that we can *find out* if the
code has got problems...

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I'm not sure if it out-ranks the advantages of the change for buildfarm
> > support, but the above change isn't actually without any disadvantage.
> > Specifically, not every auth mechanism that works with -h machine_name
> > works with -h localhost, but the first record in pg_hba which is matched
> > is used. I could have:
>
> > host all all 127.0.0.1/32 @authmethod@
> > host all all A.B.C.D/32 @authmethod2@
>
> If you've got any such thing, you've got a *nondefault* pg_hba.conf
> file. Or are you opining that people who are smart enough to set
> that up are too stupid to replace a single "samehost" entry with
> the two entries they need?

I was mainly just trying to address that 127.0.0.1->samehost is not a
change without possible downfalls, in general. If a packager imposed
or recommended such a change it could break things for end users. We do
use 'host all all 127.0.0.1/32 md5' in the default Debian configuration.
If that was later changed to 'samehost' and then the diff applied to
some configurations (something Debian wouldn't do without asking, but it
might ask if you wanted to use the maintainer's version of the file, and
I know that I've done that in the past and then added back my local
changes, especially if I can do so easily by just adding lines to the
end of the file..), things could break.

I have no idea how/if this would apply anywhere else. In general, I
think the user could figure out, but running these kind of issues down
can be annoying when it's not necessairly clear what's happening.

My comment was primairly for Martin's benefit and could probably be
resolved by just adding some commentary to the default config saying
that this might override other pg_hba lines below which used to apply
to connections over the local system's network IP.

Thanks,

Stephen

Mark Mielke <mark(at)mark(dot)mielke(dot)cc> writes:
> I would like to see the default of "trust" abolished.

We've been around on that point before and I don't see any reason to
think that the outcome of the argument would be different now. The only
reason I brought all this up is that "samehost" does change the terms of
debate for the question of what "host" lines we need to provide.

regards, tom lane

On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
> # local connections via TCP/IP:
> host all all samehost @authmethod@
>
> The advantage of this is that connections made with "-h machine_name"
> instead of "-h localhost" would work without customization. I can't
> see any disadvantage to it. Making the change now would also give
> us an opportunity to test the samehost/samenet implementation in the
> buildfarm, at least for machines without Unix sockets.
>
> (Note that you would still need a non-default setting of
> listen_addresses for "-h machine_name" to actually work.)

Which makes this proposal kind of uninteresting.

Plus, with @authmethod@ being mostly "trust", how much faith do we have
in samehost never giving any false positives?

Sounds uncomfortable to me.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> (Note that you would still need a non-default setting of
>> listen_addresses for "-h machine_name" to actually work.)

> Which makes this proposal kind of uninteresting.

Well, it's one less thing that has to be fixed for local connections
to work smoothly.

> Plus, with @authmethod@ being mostly "trust", how much faith do we have
> in samehost never giving any false positives?

Having looked at the code, I think that samehost is pretty safe. I'm
still worried about samenet picking up a bogusly broad netmask --- but
samehost hard-wires the netmask at all-ones. Even if your network
configuration is really screwed up, the kernel isn't going to send that
traffic off-machine. So I think it will act as advertised.

regards, tom lane

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
>> (Note that you would still need a non-default setting of
>> listen_addresses for "-h machine_name" to actually work.)

> Which makes this proposal kind of uninteresting.

Although come to think of it ... is there any reason besides sheer
conservatism to not make the default listen_addresses value '*'?
It won't result in letting in any outside connections unless you
also add pg_hba.conf entries.

regards, tom lane

On 1 okt 2009, at 06.53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
>>> (Note that you would still need a non-default setting of
>>> listen_addresses for "-h machine_name" to actually work.)
>
>> Which makes this proposal kind of uninteresting.
>
> Although come to think of it ... is there any reason besides sheer
> conservatism to not make the default listen_addresses value '*'?
> It won't result in letting in any outside connections unless you
> also add pg_hba.conf entries.

Absolutely. One less opportunity to DOS the server - it's certainly
cheaper to deal with connection floods by never even answering the
socket. Also, showing up in portscans for example.

Now, that trust authentication is a different issue ;)

/Magnus

On Wed, Sep 30, 2009 at 11:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Although come to think of it ... is there any reason besides sheer
> conservatism to not make the default listen_addresses value '*'?

just my 2 cents. but i always wondered about the existence of
listen_addresses at all... to me the only reason it exists is to force
me to change 'localhost' to '*' after installing, something i always
do almost automaticaly =)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Hi,

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
>>> (Note that you would still need a non-default setting of
>>> listen_addresses for "-h machine_name" to actually work.)
>
>> Which makes this proposal kind of uninteresting.

As already said, it's one less step to have it working. This hba file is
hard to get at for a lot of newbies we see on IRC. +1 for default
configuration using samehost.

> Although come to think of it ... is there any reason besides sheer
> conservatism to not make the default listen_addresses value '*'?
> It won't result in letting in any outside connections unless you
> also add pg_hba.conf entries.

Everywhere possible I have listen_addresses set to '127.0.0.1' a
pgbouncer instance for clients to connect to, on the non loopback
interface. That allows me to be sure that developers won't accidently
bypass pgbouncer. But as we're only talking about default setup, Magnus
argument weights much more (no DOS or portscan).

Regards,
--
dim

At 2009-09-30 22:08:12 -0400, tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
>
> # local connections via TCP/IP:
> host all all samehost @authmethod@

I think that's an excellent idea.

On the other hand, I tend to be slightly against the idea of changing
the default listen_addresses from localhost to '*', for a combination
of the reasons mentioned by others; but I don't have strong feelings
about it.

-- ams

* Jaime Casanova (jcasanov(at)systemguards(dot)com(dot)ec) wrote:
> just my 2 cents. but i always wondered about the existence of
> listen_addresses at all... to me the only reason it exists is to force
> me to change 'localhost' to '*' after installing, something i always
> do almost automaticaly =)

Try running two postmasters on the same box using the same port (but
different IPs) w/o being able to control what IPs it listens on.

Thanks,

Stephen

Stephen Frost wrote:
> * Jaime Casanova (jcasanov(at)systemguards(dot)com(dot)ec) wrote:
>
>> just my 2 cents. but i always wondered about the existence of
>> listen_addresses at all... to me the only reason it exists is to force
>> me to change 'localhost' to '*' after installing, something i always
>> do almost automaticaly =)
>>
>
> Try running two postmasters on the same box using the same port (but
> different IPs) w/o being able to control what IPs it listens on.
>
>
>

Right. listen_addresses replaced two previous settings: tcpip_socket and
virtual_host. And back before 8.0 the default setting was not to listen
on *any* IP address.

I'm inclined to think our default setting is about right. It is very
common to run an application on the same machine as the database server
it uses, and then there is no often need to adjust listen_addresses at all.

cheers

andrew

Tom Lane wrote:
> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
> a good idea to replace this part of the default pg_hba.conf file:

You're probably not suggesting this, but I would be against a default
setting of 'samehost' used with 'trust'.

Essentially that would be the same as rlogin rsh, where if the user can
spoof a TCP connection, he can connect to postgresql. Depending on the
platform, an interface may have to be down for this to work.

Cheers,

Stef

Tom Lane wrote:
> Having looked at the code, I think that samehost is pretty safe. I'm
> still worried about samenet picking up a bogusly broad netmask --- but
> samehost hard-wires the netmask at all-ones. Even if your network
> configuration is really screwed up, the kernel isn't going to send that
> traffic off-machine. So I think it will act as advertised.

But will it accept traffic from off machine? If so, then essentially the
only line of defense is the security of the TCP stack. Or am I missing
something?

Cheers,

Stef

Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Although come to think of it ... is there any reason besides sheer
>> conservatism to not make the default listen_addresses value '*'?
>
> just my 2 cents. but i always wondered about the existence of
> listen_addresses at all... to me the only reason it exists is to
> force me to change 'localhost' to '*' after installing, something i
> always do almost automaticaly =)

For all the reasons already given, -1 from me for changing the default
of listen_addresses or eliminating it.

Trust authentication has a few valid use cases, but it does tend to
worry me that people may leave it enabled in inappropriate situations
on production clusters. I don't see how we could get rid of it, but
I'd be OK with a warning in the log when a pg_hba.conf file is
processed which contains any trust entries.

-Kevin

On 10/01/2009 10:24 AM, Kevin Grittner wrote:
> Trust authentication has a few valid use cases, but it does tend to
> worry me that people may leave it enabled in inappropriate situations
> on production clusters. I don't see how we could get rid of it, but
> I'd be OK with a warning in the log when a pg_hba.conf file is
> processed which contains any trust entries.

I don't think "trust" needs to be removed entirely - it is a valid
option for demos or training sessions perhaps.

By using the word "abolishing", I might have created the wrong
impression. I just meant the default pg_hba.conf having "trust" has
always seemed to be a really bad thing to me.

If people already have pg_hba.conf with "trust", I see no reason to stop
them.

If a new user tries using PostgreSQL for the first time - I think the
default configuration they encounter should be conservative and usable
out of the box. I can see how "samehost" fits into this picture. I don't
see how "trust" fits into this picture. Does anybody seriously recommend
"trust" to newbies for production use? Shouldn't the default pg_hba.conf
represent a conservative recommendation from the pgsql developers?

Cheers,
mark

--
Mark Mielke<mark(at)mielke(dot)cc>

Stef Walter <stef-list(at)memberwebs(dot)com> writes:
> Tom Lane wrote:
>> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
>> a good idea to replace this part of the default pg_hba.conf file:

> You're probably not suggesting this, but I would be against a default
> setting of 'samehost' used with 'trust'.

> Essentially that would be the same as rlogin rsh, where if the user can
> spoof a TCP connection, he can connect to postgresql. Depending on the
> platform, an interface may have to be down for this to work.

Is there any actual risk here that we aren't taking already just by
allowing 127.0.0.1?

regards, tom lane

On Thu, Oct 1, 2009 at 11:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Stef Walter <stef-list(at)memberwebs(dot)com> writes:
>> Tom Lane wrote:
>>> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
>>> a good idea to replace this part of the default pg_hba.conf file:
>
>> You're probably not suggesting this, but I would be against a default
>> setting of 'samehost' used with 'trust'.
>
>> Essentially that would be the same as rlogin rsh, where if the user can
>> spoof a TCP connection, he can connect to postgresql. Depending on the
>> platform, an interface may have to be down for this to work.
>
> Is there any actual risk here that we aren't taking already just by
> allowing 127.0.0.1?

I wouldn't bet that there isn't. I don't really think there's any
need for our default configuration to be at the mercy of every half-
baked TCP/IP implementation out there. A socket file in /tmp can't be
remotely hacked (well, not directly anyway); anything else is further
from a sure thing.

...Robert

Tom Lane wrote:
> Stef Walter <stef-list(at)memberwebs(dot)com> writes:
>> Tom Lane wrote:
>>> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
>>> a good idea to replace this part of the default pg_hba.conf file:
>
>> You're probably not suggesting this, but I would be against a default
>> setting of 'samehost' used with 'trust'.
>
>> Essentially that would be the same as rlogin rsh, where if the user can
>> spoof a TCP connection, he can connect to postgresql. Depending on the
>> platform, an interface may have to be down for this to work.
>
> Is there any actual risk here that we aren't taking already just by
> allowing 127.0.0.1?

Yes, RFC 1122 specifies that 127.0.0.0/8 must not appear outside of a
single host. Checks for this are implemented. For example in FreeBSD:

http://fxr.watson.org/fxr/source/netinet/ip_input.c#L440
http://fxr.watson.org/fxr/search?string=IN_LOOPBACK

Obviously I can't guarantee this for any given OS. However it does seem
like a pretty standard security feature of the IP stack.

In my opinion, adding samehost into the default pg_hba.conf with the
method set to md5 (attached patch) would be both usable and secure.

Cheers,

Stef

Magnus Hagander wrote:
> On 1 okt 2009, at 06.53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> >> On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
> >>> (Note that you would still need a non-default setting of
> >>> listen_addresses for "-h machine_name" to actually work.)
> >
> >> Which makes this proposal kind of uninteresting.
> >
> > Although come to think of it ... is there any reason besides sheer
> > conservatism to not make the default listen_addresses value '*'?
> > It won't result in letting in any outside connections unless you
> > also add pg_hba.conf entries.
>
> Absolutely. One less opportunity to DOS the server - it's certainly
> cheaper to deal with connection floods by never even answering the
> socket. Also, showing up in portscans for example.
>
> Now, that trust authentication is a different issue ;)

I seems the purpose of listen_addresses was not clear to everyone, so I
have added the attached documentation sentence to specify its purpose.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +