Re: Allow cluster owner to bypass authentication

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> 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,

Right.

> and that's not a sensible *default*
> setting for us to have, imv.

There's certainly a discussion to be had about whether that should be
the default or not (and I too am doubtful that it should be); but I think
Peter made a sufficient case that it'd be useful if it were easy to set
things up that way. Right now it's a tad painful.

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

Maybe, but then we'd need to allow multiple map options. Still, if
the semantics are "union of what any map allows", that doesn't
seem too hard.

> Allowing multiple maps to be used is a different feature.

Not really; I think it is quite reasonable to want "OS owner can
connect as anyone" plus "joe should be allowed to connect as charlie".
If you want to add the latter to a working setup, you shouldn't have
to suddenly figure out how to reimplement "map=pg_os_user_allow" at
a lower level of detail. That's a recipe for mistakes.

regards, tom lane