Greetings,
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> The idea is that if you connect over a Unix-domain socket and the local
> (effective) user is the same as the server's (effective) user, then
> access should be granted immediately without any checking of
> pg_hba.conf. Because it's "your own" server and you can do anything you
> want with it anyway.
While I understand where you're generally coming from, I'm not entirely
convinced that this is a good direction to go in. Yes, you could go
change pg_hba.conf (maybe..)- but would doing so trigger an email to
someone else? Would you really be able to change pg_hba.conf when you
consider more restrictive environments, like where there are SELinux
checks? These days, a simple getpeerid() doesn't actually convey all of
the information about a process that would let you be confident that the
client really has the same access to the system that the running PG
server does.
> I included an option to turn this off because (a) people are going to
> complain, (b) you need this for the test suites to be able to test
> pg_hba.conf, and (c) conceivably, someone might want to have all access
> to go through pg_hba.conf for some auditing reasons (perhaps via PAM).
Auditing is certainly an important consideration.
> This addresses the shortcomings of using peer as the default mechanism
> in initdb. In a subsequent step, my idea would be to make the default
> initdb authentication setup to use md5 (or scram, tbd.) for both local
> and host.
I'm definitely in favor of having 'peer' be used by default in initdb.
I am, however, slightly confused as to why we'd then want to, in a
subsequent step, make the default set up use md5 or scram...?
* Andrew Dunstan (andrew.dunstan@2ndquadrant.com) wrote:
> This has been hanging around for a while. I guess the reason it hasn't
> got much attention is that on its own it's not terribly useful.
> However, when you consider that it's a sensible prelude to setting a
> more secure default for auth in initdb (I'd strongly advocate
> SCRAM-SHA-256 for that) it takes on much more significance.
I'm all for improving the default for auth in initdb, but why wouldn't
that be peer auth first, followed by SCRAM..? If that's what you're
suggesting then great, but that wasn't very clear from the email text,
at least. I've not done more than glanced at the patch.
Thanks,
Stephen