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
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 |