Re: Allow cluster owner to bypass authentication

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow cluster owner to bypass authentication
Date: 2019-12-27 18:08:09
Message-ID: 12715.1577470089@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> Well, if this is the pg_hba.conf setup and I am considering the
> authentication method when creating new users, then my only safe option
> is to not create any new users. Because which OS users exist is not
> controlled by the DBA. If the OS admin and the DBA are the same entity,
> then peer is obviously very nice, but if not, then peer is a trap.

Not sure about whether this is an interesting consideration or not.
If you don't trust the OS-level admin, don't you basically need to
go find a different computer to work on?

Still, I take your point that "peer" does risk letting in a set of
connections wider than what the DBA was thinking about. Enlarging
on my other response that what we want is an auth option not a whole
new auth type, maybe we could invent another auth option that limits
which OS user names are accepted by "peer", with an easy special case
if you only want to allow the server's OS owner. (Note that this
is *not* the existing "role" column, which restricts the database
role name not the external name; nor is it something you can do
with a username map, at least not with the current definition of
those.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-12-27 19:13:42 Re: Improvement to psql's connection defaults
Previous Message Tom Lane 2019-12-27 17:59:04 Re: Allow cluster owner to bypass authentication