Re: Allow cluster owner to bypass authentication

Greetings,

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

I'm also concerned with the "where does this end?" question.  What if
the role is set to not allow connections?  What if the database is set
to not allow connections?  I mean, sure, it's the OS user, so they can
do *anything*, technically, but we generally want some intelligent
safe-guards in place where we make them jump through an extra hoop or
two to make a change that could really break things.  Further, some of
those "safe-guards" that we have might be "auditing requirements" to
other people who expect to see in their audit logs when a change is made
to, say, allow the OS user to log in as some other role.  I suppose as
long as this can be turned off (and, ideally, isn't the default anyway)
then hopefully it won't be too much of an issue.

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

I agree that doesn't seem too hard and generally seems reasonable.
Seems like we might also want an explicit way of saying '*' on the
right-hand-side, or something like it, so users could set this up for
anyone they want and not only have this option exist for the user who
happens to be logging in with the same unix uid of the PG server.

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

Eh, I wouldn't argue if someone wrote a single patch that does both, but
considering we don't support multiple maps today, I wouldn't push on
someone wanting to extend the way maps work today to require that they
implement support for multiple maps too.

Thanks,

Stephen