Re: Allow cluster owner to bypass authentication

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > 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
>
> But ... if "peer" auth allowed all the cases Peter wants to allow,
> we'd not be having this discussion in the first place, would we?

I'm still not entirely convinced it doesn't, but that's also because I
keep thinking we're talking about a sensible default here and I'm coming
to realize that the idea here is to let the cluster owner not just
bypass auth to connect as their own DB user, but to allow the cluster
own to connect as ANY database role, and that's not a sensible *default*
setting for us to have, imv.

> The specific case of concern here is the database's OS-owner wanting
> to connect as some other database role than her OS user name.
> "peer" doesn't allow that, at least not without messy additional
> configuration in the form of a username map.

Yes, to allow that you'd need to have a mapping. Theoretically, we
could have a mapping automatically exist which could be used for that,
but now I'm trying to understand what the use-case here is for actual
deployments. If this is for testing- great, let's have some flag
somewhere that we can enable for testing but we shouldn't have it as the
*default*.

> While the syntax you suggest above could be made to implement that,
> it doesn't seem very intuitive to me. Maybe what we want is some
> additional option that acts like a prefab username map:
>
> local all all peer let_OS_owner_in_as_any_role

Or ... map=pg_os_user_allow

and declare 'pg_*' as system-defined special mappings, like "OS user" ->
"anyone".

> Bikeshedding the actual option name is left for the reader. We'd
> also have to think whether a regular "map" option can be allowed
> on the same line, and if so how the two would interact. (It might
> be as easy as "allow connection if either option allows it".)

Allowing multiple maps to be used is a different feature.

Thanks,

Stephen