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:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> Still, I take your point that "peer" does risk letting in a set of
> >> connections wider than what the DBA was thinking about. Enlarging
> >> on my other response that what we want is an auth option not a whole
> >> new auth type, maybe we could invent another auth option that limits
> >> which OS user names are accepted by "peer", with an easy special case
> >> if you only want to allow the server's OS owner. (Note that this
> >> is *not* the existing "role" column, which restricts the database
> >> role name not the external name; nor is it something you can do
> >> with a username map, at least not with the current definition of
> >> those.)
>
> > Sure you can do this with an existing map- just define a mapping and
> > only include in it the users you want to allow. If no mapping matches,
> > then your connection is denied.
>
> Oh, hm ... that wasn't my mental model of it, and the documentation
> doesn't really spell that out anywhere.

That documentation also refers to 'ident' still, unfortunately.

> It would be reasonable for
> people to assume that the default behavior is equivalent to a map
> with no entries, and I don't see anything in the docs that really
> contradicts that. As best I can tell from the above, the default
> corresponds to an explicitly-written map like
>
> default /^(.*)$ \1
>
> which seems unreasonably complicated; it's sure going to look
> like line noise to somebody who's not already familiar with
> regex notation.

Right- the default mapping is an 'equality' mapping, which, implemented
as a regexp, looks like the above. When it comes to what happens when
you add 'map=' to an entry in your pg_hba.conf, I view that as "I am
replacing the default mapping with this one of my own". That's
necessary if your OS users don't map to your DB users (I want to be able
to support having 'alice' map to 'bob', and 'bob' map to 'alice',
without 'alice' being allowed to log in as 'alice' or 'bob' to log in as
'bob'...).

> The other issue is that you can't actually implement the behavior
> Peter wants with the existing username map facility, because there's
> no wildcard for the database role name column. You can't write
>
> pg_os_user_allow postgres .*
>
> and even if you could, that's not a great solution because it
> hard-wires the OS username of the database server's owner.

Yeah, that is true, though we could make both halves of that work, I
would think.

> I think it'd be great if this behavior could be implemented
> within the notation, because we could then just set up a
> non-empty default pg_ident.conf with useful behavioral
> examples in the form of prefab maps. In particular, we
> should think about how hard it is to do "I want the default
> behavior plus allow joe to connect as charlie". If the
> default is a one-liner that you can copy and add to,
> that's a lot better than if you have to reverse-engineer
> what to write.

This direction certainly sounds more appealing to me.

Thanks,

Stephen