On Fri, Oct 28, 2022 at 5:26 PM Bryn Llewellyn <b...@yugabyte.com> wrote:
> > And I simply decided to follow its spirit with "bob" mapping to "alice", > thus: > > *# MAPNAME SYSTEM-USERNAME PG-USERNAME* > > > *...bllewell bob alice* > Here's my "pg_hba.conf": > > > *...* > > > > > > *local all postgres peer # > See the essay at the start.local all alice > peerlocal all bob > peerlocal all all > peer...* > So, none of those make use of the mapping (named bllewell) that you created since you don't have a map option as described here: https://www.postgresql.org/docs/current/auth-username-maps.html "To use user name mapping, specify map=map-name in the options field in pg_hba.conf." > Then I did "su bob" and first did this sanity test: > > *psql -h localhost -p 5432 -d postgres -U alice* > I don't see how that worked given the above observation... > > Finally, I omitted "bob" here in the belief that this would make my > mapping kick in and authorize using the cluster role "alice": > > > *psql -d postgres* > > It got me in without error. (And, as hoped for, there was no password > challenge.) But "select current_role" showed that the mapping had been > ignored and that I was connected again as "bob". > > *What am I doing wrong?* > > As noted elsewhere, the name you specify on the psql command line, whether chosen by default or explicitly, will be the name you end up connected as should your connection attempt be accepted. The mapping file simply allows the DBA to accept a role name that you specify that, in the case of peer, is different than the o/s user name you are physically establishing the connection over. In short, bob can request to login as alice but the database is not going to peer authenticate that request unless the pg_ident.conf file says that it ok for bob (o/s) to be alice (system). David J.
