On 2019-12-17 05:40, Stephen Frost wrote:
* Peter Eisentraut (peter.eisentr...@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 realize that there are a number of facilities nowadays to do enhanced
security setups. But let's consider what 99% of users are using. If
the database server runs as user X and you are logged in as user X, you
should be able to manage the database server that is running as user X
without further restrictions. Anything else would call into question
the entire security model that postgres is built around. But also,
there is an option to turn this off in my patch, if you really have the
need.
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.
'peer' is not good default for initdb. Consider setting up a database
server on a notional multiuser host with peer authentication. As soon
as you create a database user, that would allow some random OS user to
log into your database server, if the name matches. 'peer' is useful if
there is a strong coordination between the OS user creation and the
database user creation. But the default set up by initdb should really
only let the instance owner in by default and require some additional
authentication (like passwords) from everybody else. 'peer' cannot
express that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
