Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Subject: Re: Support for NSS as a libpq TLS backend
From: Daniel Gustafsson <daniel@yesql.se>
In-Reply-To: <50c5a423329ea9996a2a2b167931711189ed5d1b.camel@vmware.com>
Date: Thu, 27 May 2021 22:31:07 +0200
Cc: "sfrost@snowman.net" <sfrost@snowman.net>,
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 "hlinnaka@iki.fi" <hlinnaka@iki.fi>,
 "andrew.dunstan@2ndquadrant.com" <andrew.dunstan@2ndquadrant.com>,
 "thomas.munro@gmail.com" <thomas.munro@gmail.com>,
 "michael@paquier.xyz" <michael@paquier.xyz>,
 "andres@anarazel.de" <andres@anarazel.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FD5BB88-595A-47A0-8F51-0A1B5EEC93FA@yesql.se>
References: <1b16041447d57b45ca273f41d26f6e298d756f99.camel@vmware.com>
 <04E81B50-ACE9-40D3-9C66-7041F969A958@yesql.se>
 <21FABD55-5F80-4D8B-B994-3DB81D8742EE@yesql.se>
 <20210321234950.GQ20766@tamriel.snowman.net>
 <F25D6A6A-8FCB-4188-B6E5-5587BABE4D3E@yesql.se>
 <743a11e6668bef648c7a53f862038e6b2fad3755.camel@vmware.com>
 <YFqHmspKASMHcH7V@paquier.xyz>
 <05da9d530ab01e6959bd50c993d590ad73575c21.camel@vmware.com>
 <20210324170036.GS20766@tamriel.snowman.net>
 <8f741a425fd135ca38a28063730715499f7f6445.camel@vmware.com>
 <20210324181016.GU20766@tamriel.snowman.net>
 <50c5a423329ea9996a2a2b167931711189ed5d1b.camel@vmware.com>
To: Jacob Champion <pchampion@vmware.com>
Archived-At: 
 <https://www.postgresql.org/message-id/2FD5BB88-595A-47A0-8F51-0A1B5EEC93FA%40yesql.se>
Precedence: bulk

> 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 those databases =
seemingly can't be referenced directly by nickname. They have to be =
prefixed by their token name -- a name which 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 =
whether our 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/