Re: allowing "map" for password auth methods with clientcert=verify-full

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: allowing "map" for password auth methods with clientcert=verify-full
Date: 2021-10-26 22:16:34
Message-ID: 176308.1635286594@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jonathan S. Katz" <jkatz(at)postgresql(dot)org> writes:
> On 10/26/21 3:26 PM, Tom Lane wrote:
>> I think this is conflating two different things: a mapping from the
>> username given in the startup packet, and a mapping from the TLS
>> certificate CN. Using the same keyword and terminology for both
>> is going to lead to pain. I'm on board with the idea if we can
>> disentangle that, though.

> Hm, don't we already have that already when using "cert" combined with
> the "map" parameter? This is the main reason I "stumbled" upon this
> recommendation.

I'm not exactly convinced that the existing design is any good.
I'm suggesting that we stop and think about it before propagating
it to a bunch of other use-cases.

Per "21.2. User Name Maps", I think that the map parameter is supposed
to translate from the startup packet's user name to the SQL role name.
ISTM that what is in the cert CN might be different from either
(particularly by perhaps having a domain name attached). So I'd be
happier if there were a separate mapping available for the CN.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-10-26 22:31:05 Re: Assorted improvements in pg_dump
Previous Message Mark Dilger 2021-10-26 22:08:37 Re: Feature request for adoptive indexes