On 24/04/13 09:39, Nathan Scott wrote:
> ...
>> 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.
I've already done that when I committed my change for PCP_SECURE_DB_METHOD.
>> 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?
Yep, that is probably a more correct explanation.
>> 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).
Agreed ... the certificate loading probably should be guarded by a one-trip
thread-safe state variable and delayed until we're about to do pmNewContext()
with either (a) PCP_SECURE_SOCKET set to one of the magic values in the
environment, or (b) PM_CTXFLAG_SECURE is set in the type parameter to
pmNewContext().
> 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.
In my regression environment, $NSS_DEFAULT_DB_TYPE does not change the
behaviour at all. This is with my code change (so sql: is removed by setting
$PCP_SECURE_DB_METHOD to an empty string). I think this is very close to the
behaviour you're planning/expecting.
kenj@vm04:~$ rm -rf ~/.pki
kenj@vm04:~$ export NSS_DEFAULT_DB_TYPE=sql
kenj@vm04:~$ export PCP_SECURE_DB_METHOD=''
kenj@vm04:~$ pmprobe sample.long.one
sample.long.one 1
kenj@vm04:~$ unset NSS_DEFAULT_DB_TYPE
kenj@vm04:~$ pmprobe sample.long.one
sample.long.one 1
kenj@vm04:~$ ls -R ~/.pki
/home/kenj/.pki:
nssdb
/home/kenj/.pki/nssdb:
cert8.db key3.db secmod.db
kenj@vm04:~$ file ~/.pki/nssdb/*
/home/kenj/.pki/nssdb/cert8.db: Berkeley DB 1.85 (Hash, version 2, native
byte-order)
/home/kenj/.pki/nssdb/key3.db: Berkeley DB 1.85 (Hash, version 2, native
byte-order)
/home/kenj/.pki/nssdb/secmod.db: Berkeley DB 1.85 (Hash, version 2, native
byte-order)
> I believe this will allow us to provide our preference (new format) but also
> co-exist with down-rev nss, and the users preferences.
My only concern with this is that it changes the default behaviour from what we
did in the previous release.
|