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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: allowing "map" for password auth methods with clientcert=verify-full
Дата
Msg-id 176308.1635286594@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: allowing "map" for password auth methods with clientcert=verify-full  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Ответы Re: allowing "map" for password auth methods with clientcert=verify-full  (Andrew Dunstan <andrew@dunslane.net>)
Re: allowing "map" for password auth methods with clientcert=verify-full  (Jacob Champion <pchampion@vmware.com>)
Список pgsql-hackers
"Jonathan S. Katz" <jkatz@postgresql.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: Feature request for adoptive indexes
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Assorted improvements in pg_dump