If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

PK11_ListCerts is unable to dynamically pick up new certificate from cert9.db and key4.db

RESOLVED INVALID

Status

NSS
Libraries
RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: Meena Vyas, Unassigned)

Tracking

3.13.1
x86_64
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
PK11_ListCerts is unable to dynamically pick up new certificate from cert9.db and key4.db
so I created a simple setup to show the problem.

Steps to reproduce the problem : 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ mkdir source tmp dest
$ certutil -N -d sql:source
$ cp source/* dest/
-----------------
In one window run
$certutil -B -i /dev/stdin  -d sql:./dest/
-L
Doesn't show any certificates.
-------------
cat > run.sh 

rm noise.tmp
echo `date` | tee noise.tmp
../bin/certutil -S -k rsa -g 2048 -t u,u,u -s CN=$1.cert -8 $1.cert -n $1.certnick -v 12 -d ./source -Z SHA1 -z noise.tmp -x 
cp ./source/cert9.db ./tmp/cert9.db
cp ./source/key4.db ./tmp/key4.db
cp ./source/pkcs11.txt ./tmp/pkcs11.txt
mv ./tmp/cert9.db ./dest/
mv ./tmp/key4.db ./dest/
mv ./tmp/pkcs11.txt ./dest/
----------------

In another window run these one by one to create certs :
sh -x run.sh 1
sh -x run.sh 2
sh -x run.sh 3
----------------------
In the first window type -L, its not showing the newer certs.

If I copy the DBs directly its ok. If I copy it to a temporary directory and do "mv", certutil is unable to pick up newer certs.
(Reporter)

Comment 1

5 years ago
Even if it is not possible to fix this bug its ok. Just wondering if its a good idea to fix this or not. 

Probably NSS is opening cert9.db/key4.db using open() and passing that file descriptor to fstat() to see if the size of cert9.db and key4.db has changed. 

My program has :
    int fd = open("a")...
    while (1) {
        fstat(fd,sb);
        printf("size=%d, nlink=%d, ino=%d",....);
        getchar(); // if we give any char input it calls fstat again and prints info
    }

Initially file "a" :
$./a.out
size=11
nlink=1
ino=7474033
==================
In another window, copy a file, its able to detect the changes.
$ cp b a
==================
in older window, press any character, so it calls fstat again : 

size=36
nlink=1
ino=7474033

we see that it returns stuff correctly, size of the file has changed inode remains the same.
============
Now in another window move a file "c" to "a".

$ mv c a
$ ls -i a
7471804 a
=============
in older window, press any character, so it calls fstat again : 
size=36
nlink=0
ino=7474033

Although "mv" changes the inode of this file "a" to that of "c", fd in our program still points to old "a" so its returning old data and is unable to detect file size changes.

Comment 2

5 years ago
Sorry Meena but this test case is invalid, you can't overwrite the DB files with cp.
You must NSS programs to modify the DB. Otherwise the DB will not be multi-process safe. It is only safe between multiple NSS applications.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.