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

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>