pcp
[Top] [All Lists]

Re: [pcp] pcp updates - overcome secure sockets breakage

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] pcp updates - overcome secure sockets breakage
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 24 Apr 2013 20:13:46 +1000
Cc: "Frank Ch. Eigler" <fche@xxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1682528883.2999675.1366772707480.JavaMail.root@xxxxxxxxxx>
References: <51762D9B.3090702@xxxxxxxxxxxxxxxx> <y0mli89cqi3.fsf@xxxxxxxx> <5176F9A3.9040705@xxxxxxxxxxxxxxxx> <1990339191.2954455.1366760353823.JavaMail.root@xxxxxxxxxx> <51773F44.3050108@xxxxxxxxxxxxxxxx> <20130424022216.GB29062@xxxxxxxxxx> <1682528883.2999675.1366772707480.JavaMail.root@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
On 24/04/13 13:05, Nathan Scott wrote:
> 
> ----- Original Message -----
>> Right.  Would you mind trying the same test on a RHEL6-era type box too,
>> where
>> nss >= v3.12 ?  There should be a sqlite cert9.db / key4.db created.
>>
> 
> I just tried Kens latest code on RHEL6 & it does indeed create an
> SQL database, with no extra magic in the environment other than
> PCP_SECURE_SOCKETS=enforce).

That is what I'd expect.  But when I tried it on Centos 6.3 I did necessarily 
not expect all of the following ...

- when no certificates are installed for pmcd in /etc/pki and without 
PCP_SECURE_SOCKETS=enforce the client succeeds and the directory ~/.pki/nssdb 
is populated with empty SQLite databases

- when no certificates are installed for pmcd in /etc/pki and with 
PCP_SECURE_SOCKETS=enforce the client fails with "Operation not supported" and 
the directory ~/.pki/nssdb is populated with empty SQLite databases

- when no certificates are installed for pmcd in /etc/pki and with 
PCP_SECURE_DB_METHOD='' the client succeeds and the directory ~/.pki/nssdb is 
populated with empty Berkeley DB databases

- when no certificates are installed for pmcd in /etc/pki and a client is run 
first with PCP_SECURE_DB_METHOD='' and then with PCP_SECURE_DB_METHOD unset (or 
set to sql:) (or in the other order), the client succeeds both times and the 
directory ~/.pki/nssdb is populated with *both* empty Berkeley DB databases and 
empty SQLite databases

- before any PCP installation is done, /etc/pki/nssdb already exists and is 
populated with files for _both_ the version 3 format (Berkeley DB) and the 
version 4 format (SQLite), although both databases are empty

- when certificates are installed for pmcd in /etc/pki using the sql: method 
and pmcd is restarted, the next PCP client without PCP_SECURE_SOCKETS=enforce 
succeeds, but with PCP_SECURE_SOCKETS=enforce the certificate save fails with 
the "PKCS#11 token is not logged in" error

- if ~/.pki/nssdb is removed and repopulated with an empty database, as in
        rm -rf $HOME/.pki
        mkdir -p -m 0755 $HOME/.pki/nssdb
        certutil -d sql:$HOME/.pki/nssdb -N -f /tmp/empty
then the certificate is saved correctly, the client succeeds and subsequent 
clients do not trigger the certificate save dialog

- now repeating this with the Berkeley DB format alongside the SQLite format 
files ...
        certutil -d $HOME/.pki/nssdb -N -f /tmp/empty
and then
        PCP_SECURE_SOCKETS=enforce PCP_SECURE_DB_METHOD='' pmclient command
saves the certificate the first time and always succeeds

- interestingly, if you remove ~/.pki and rerun the command
        PCP_SECURE_SOCKETS=enforce PCP_SECURE_DB_METHOD='' pmclient command
we get the save certificate dialog, and the certificate is saved and the 
command succeeds, plus subsequent clients do not trigger the certificate save 
dialog

> In other interesting news ... I've suddenly started seeing the other
> warnings Ken has observed, i.e.
> "The operation failed because the PKCS#11 token is not logged in."
> 

We now know that certutil and chrome are doing the right thing when these 
SQLite DBs are being created, but PCP is not ... although PCP is doing the 
right thing for the Berkeley DB format.

I think we're getting closer ... tomorrow I may circle back to the Centos 5.x 
system and go through this same sequence of tests.

<Prev in Thread] Current Thread [Next in Thread>