Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > Well, if this is the pg_hba.conf setup and I am considering the
> > authentication method when creating new users, then my only safe option
> > is to not create any new users. Because which OS users exist is not
> > controlled by the DBA. If the OS admin and the DBA are the same entity,
> > then peer is obviously very nice, but if not, then peer is a trap.
>
> Not sure about whether this is an interesting consideration or not.
> If you don't trust the OS-level admin, don't you basically need to
> go find a different computer to work on?
>
> 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.
If you want an equality match in your mapping, then you have to provide
one, like so:
default /^(.*)$ \1
Thanks,
Stephen
