Re: Allow cluster owner to bypass authentication

On 2019-12-17 05:40, Stephen Frost wrote:
> * 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 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