Stephen Frost <sfr...@snowman.net> writes:
> * Tom Lane (t...@sss.pgh.pa.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
