From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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 17:35:51 |
Message-ID: | 20191227173551.GR3195@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com) wrote:
> On 2019-12-18 15:09, Robert Haas wrote:
> >I feel like this is taking a policy decision that properly belongs in
> >pg_hba.conf and making it into a GUC. If you're introducing a GUC
> >because it's not possible to configure the behavior that you want in
> >pg_hba.conf, then I think the solution to that is to enhance
> >pg_hba.conf so that it can support the behavior you want to configure.
>
> Yeah, I was not really happy with that either. So I tried a new approach:
> Introduce a new pg_hba.conf line type "localowner" that matches on
> Unix-domain socket connections if the user at the client end matches the
> owner of the postgres process. Then the behavior I'm after can be expressed
> with a pg_hba.conf entry like
>
> localowner all all trust
>
> or similar, as one chooses.
Ugh, no thanks. We already have enough top-level "Types" that I really
don't like inventing another that's "almost like this other one, but not
quite".
Why not have a special user that can be used for Type: local pg_hba.conf
lines? So you'd have:
local all localowner peer
That way you're:
a) only keeping the types we have today
b) using peer auth, which is what this actually is
c) NOT using 'trust', which we shouldn't because it's bad
d) matching up to what Debian has been doing for decades already
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2019-12-27 17:49:46 | Re: Allow cluster owner to bypass authentication |
Previous Message | Peter Eisentraut | 2019-12-27 17:32:29 | Re: Allow cluster owner to bypass authentication |