Re: Support for NSS as a libpq TLS backend

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Support for NSS as a libpq TLS backend
Дата
Msg-id 2FD5BB88-595A-47A0-8F51-0A1B5EEC93FA@yesql.se
обсуждение исходный текст
Ответ на Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
Ответы Re: Support for NSS as a libpq TLS backend  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
> On 25 Mar 2021, at 00:56, Jacob Champion <pchampion@vmware.com> wrote:

> Databases that are opened *after* the first one are given their own separate slots. Any certificates that are part of
thosedatabases seemingly can't be referenced directly by nickname. They have to be prefixed by their token name -- a
namewhich you don't have if you used NSS_InitContext() to create the database. You have to use SECMOD_OpenUserDB()
instead.This explains some strange failures I was seeing in local testing, where the order of InitContext determined
whetherour client certificate selection succeeded or failed. 

Sorry for the latency is responding, but I'm now back from parental leave.

AFAICT the tokenname for the database can be set with the dbTokenDescription
member in the NSSInitParameters struct passed to NSS_InitContext() (documented
in nss.h).  Using this we can avoid the messier SECMOD machinery and use the
token in the auth callback to refer to the database we loaded.  I hacked this
up in my local tree (rebased patchset coming soon) and it seems to work as
intended.

--
Daniel Gustafsson        https://vmware.com/




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: storing an explicit nonce