----- Original Message -----
> G'day Frank.
>
> On 23/04/13 23:42, Frank Ch. Eigler wrote:
> > ...
> >> Note that $NSS_DEFAULT_DB_TYPE is not an option as this apparently
> >> intended for compatibility support in the other direction,
> >> as "sql" appears to be the only well-defined value for this
> >> environment variable to enable the "new" method.
> >
> > Can you elaborate please? The model of this variable is that even if
> > it is set to "sql" (with certificate file names unadorned by the sql:
> > prefix), older versions of NSS such as on RHEL5 will ignore it, and
> > use plain berkeleydb data files. Current versions of NSS will use it
> > as an implicit prefix. What's not suitable about this?
>
> I don't see evidence of NSS_DEFAULT_DB_TYPE helping at all in my situation.
We'd need to change our code first before this setting could take effect.
Because we are explicitly requesting the sql: prefix, that is honoured
over the environment variable. If we took that out, I think the situation
might improve. At least, that's my understanding from reading utilpars.c
_NSSUTIL_EvaluateConfigDir() in the nss sources, which appears to be the
root of all configdir setup evil.
> Here's a typical session ...
>
> kenj@vm04:~$ env | egrep 'PCP|NSS'
> kenj@vm04:~$ ls -l ~/.pki
> ls: /home/kenj/.pki: No such file or directory
> kenj@vm04:~$ pmprobe sample.long.one
> [Wed Apr 24 06:59:03] pmprobe(32133) Warning: __pmConnectPMCD: certificate
> database exists, but failed initialization
> sample.long.one 1
>
> This warning is the problem that is breaking QA and is a regression over
> previous behaviour.
*nod*
> I believe it is because this empty directory structure is created (I still
I think the presence/absence of this directory isn't the root of the issue
here - rather, its more likely the call to NSS_InitReadWrite thats failing,
and probably because "sql:/home/kenj/.pki/nssdb" is not correctly understood
by this particular platforms NSS version?
> believe this creation is bogus, but that is another discussion I'm
> apparently not winning ...)
Not "not winning" - its more that its not clear how to tackle this in a
way that ensures the initialisation is done at an appropriate time (sorry,
I shoulda mentioned it wasn't obvious after an initial look into it). I'd
still like to see it cleaned up. I also didn't think it would fix the
original sudo issue, so I set it aside for now as a solution looking for a
problem (but still inclining toward fixing it).
> And further I believe it is because our code is using the sql: prefix when it
> tries to (again bogusly IMHO) load certificates even though the client has
> no interest in secure sockets (and indeed there is no certificate for pmcd
> in this installation).
>
> This produces the same result (as expected)
>
> kenj@vm04:~$ export NSS_DEFAULT_DB_TYPE=sql
> ...
> > (I believe nathans was going to test modern NSS's behavior about its
> > run-time searching behavior, in case sql: or non-sql: databases are
> > found in its target directory. It may turn out that this
> > $NSS_DEFAULT_DB_TYPE-or-equivalent need only be specified
> > once: at certificate db creation time.)
AIUI, it needs to be set at the time we call NSS_InitReadWrite().
> Maybe, but my evidence suggests it is load certificate time that is the
> problem.
*nod*
> Now having said all this, my "fix" addresses the regression ... I still have
> not had any success in making secure sockets actually work on this platform,
> although I can clearly create berkeley-style databases.
The solution I was planning to attempt when I had a moment to come back to it,
was to remove the explicit sql: prefixing in our code, then add in a putenv of
NSS_DEFAULT_DB_TYPE=sql in the lead-up to NSS_InitReadWrite(). I also think it
would be better behaviour on our part to honour user-setting of that variable,
so only putenv if its not already set.
I believe this will allow us to provide our preference (new format) but also
co-exist with down-rev nss, and the users preferences.
cheers.
--
Nathan
|