When root tries to add certs to the system nssdb, (certutil -d sql:/etc/pki/nssdb -E ...'), they end up in /root/.pki/nssdb instead, which is not so useful. I suspect that the nsssysinit module should avoid doing its tricks if it's running as root -- it should just use the specified database directly, in read-write mode. One way to make it work is to temporarily _disable_ the shared database by running 'setup-nsssysinit.sh off'. Another trick I use elsewhere, because I don't want to change the system configuration even temporarily, is to symlink /etc/pki/nssdb/{cert9.db,key4.db} into a new temporary directory and then point certutil at that directory.
Kai, David, please could you look at bug 539994 whether it is related? All the boinc communication stopped suddenly working and I found .pki/nssdb in /var/lib/boinc (home directory of user boinc).
Hm, provided that "setup-nsssysinit.sh off" helped, it is:( This is quite a problem, please try to fix this soon.
*** Bug 539994 has been marked as a duplicate of this bug. ***
Created attachment 380575 [details] allows root to open the nss system database read and write
If anyone needs to test something soon a scratch build is available at http://koji.fedoraproject.org/koji/taskinfo?taskID=1892977
The patch looks good as far as it goes. I see two potential issues: 1: It might be better to check to see if we are root and not open the user DB so that the root DB stays the default. (otherwise you will need the -h flag in certutil to modify the system db). I think this will supply the semantic that users are more likely to expect. 2: It looks like you are removing the if (filename && 0) { } test. It's effectively off, but I think we should keep it around until we figure out why it wasn't working. I think it's because you started with an older version of the file when you made your mods. bob
OTOH my other patch (with the filename && 0) probably ought not to be necessary. All apps in Fedora which use NSS ought to be explicitly opening sql:/etc/pki/nssdb rather than the legacy per-application database, so the hack should be unnecessary.
After chatting with Bob I am going to restore David's (filename && 0) { } block as we should try to make this work. Some products may have legitimate reasons for having their own application-specific NSS configuration directory. In the spirit of keeping policy separate from implementation this code enables system administration to specify policy it shouldn't impose one. New patch coming soon.
Created attachment 382129 [details] patch v2 Address Bob's review comments.
Created attachment 382133 [details] patch v3 Apply the !userIsRoot condition to the disabled code as well.
(In reply to comment #8) > After chatting with Bob I am going to restore David's (filename && 0) { } block > as we should try to make this work. Some products may have legitimate reasons > for having their own application-specific NSS configuration directory. They can do that anyway -- and they wouldn't be doing it this way. That was a hack to cope with legacy applications which haven't yet been updated to use sql:/etc/pki/nssdb for their DB. By putting a copy of the system pkcs11.txt file into the application directory (e.g. ~/.evolution) _and_ exporting NSS_DEFAULT_DB_TYPE=sql, we can 'trick' such an application into loading the libnsssysinit.so module. Only then does it make any sense for my hack to actually load the database in the app-specified directory. Except that it doesn't make _much_ sense, because the whole point in the process was that the user wants the legacy application to use the _system_ database. It's not even as if the old contents of the app-specific database are available; with NSS_DEFAULT_DB_TYPE=sql it uses _different_ files. So my old Evolution cert database is inaccessible anyway. If there's an application which wants to have its own storage, then either it wouldn't be using the nsssysinit module at all, or it can easily add an extra database for itself -- if it wants to have some private key which is _really_ private, for example. In no circumstances does it really make sense to include my hack, surely? We _should_, however, file bugs against all NSS-using applications which have not yet been converted to use sql:/etc/pki/nssdb.
nss-3.12.5-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/nss-3.12.5-2.fc12
nss-3.12.5-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0262
Hm, not so shiny. After updating, I now get this SEGV when trying to push a Fedora package update... Starting program: /usr/bin/python /usr/bin/bodhi --new --release F11 --file bodhi.template openconnect-2.20-1.fc11 -u dwmw2 [Thread debugging using libthread_db enabled] Creating a new update for openconnect-2.20-1.fc11 Program received signal SIGSEGV, Segmentation fault. __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:99 99 movlpd (%rdi), %xmm1 (gdb) bt #0 __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:99 #1 0x00007fffed46323f in get_list ( stripped_parameters=0xa2bf00 " certPrefix='' keyPrefix='' secmod='' flags=readOnly updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDescription='' ", filename=0x0) at nsssysinit.c:255 #2 NSS_ReturnModuleSpecData ( stripped_parameters=0xa2bf00 " certPrefix='' keyPrefix='' secmod='' flags=readOnly updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDescription='' ", filename=0x0) at nsssysinit.c:420 #3 0x000000352dc4a359 in SECMOD_LoadModule ( modulespec=0xa2c240 "library=\"libnsssysinit.so\" name=\"NSS Internal PKCS #11 Module\" NSS=\"Flags=internal,moduleDBOnly,critical trustOrder=75 cipherOrder=100 slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,"..., parent=<value optimized out>, recurse=<value optimized out>) at pk11pars.c:1126 #4 0x000000352dc4a3a0 in SECMOD_LoadModule ( modulespec=0xa2a800 "name=\"NSS Internal Module\" parameters=\"configdir='sql:/etc/pki/nssdb' certPrefix='' keyPrefix='' secmod='' flags=readOnly updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDes"..., parent=<value optimized out>, recurse=<value optimized out>) at pk11pars.c:1143 #5 0x000000352dc19346 in nss_InitModules (isContextInit=<value optimized out>, optimizeSpace=<value optimized out>, forceOpen=<value optimized out>, noModDB=<value optimized out>, noCertDB=<value optimized out>, readOnly=<value optimized out>, pwRequired=<value optimized out>, configStrings=<value optimized out>, configName=<value optimized out>, updateName=<value optimized out>, updateID=<value optimized out>, updKeyPrefix=<value optimized out>, updCertPrefix=<value optimized out>, updateDir=<value optimized out>, secmodName=<value optimized out>, keyPrefix=<value optimized out>, certPrefix=<value optimized out>, configdir=<value optimized out>) at nssinit.c:463 #6 nss_Init (isContextInit=<value optimized out>, optimizeSpace=<value optimized out>, forceOpen=<value optimized out>, noModDB=<value optimized out>, noCertDB=<value optimized out>, readOnly=<value optimized out>, pwRequired=<value optimized out>, configStrings=<value optimized out>, configName=<value optimized out>, updateName=<value optimized out>, updateID=<value optimized out>, updKeyPrefix=<value optimized out>, updCertPrefix=<value optimized out>, updateDir=<value optimized out>, secmodName=<value optimized out>, keyPrefix=<value optimized out>, certPrefix=<value optimized out>, configdir=<value optimized out>) at nssinit.c:622 #7 0x000000352dc19d33 in NSS_Initialize (configdir=<value optimized out>, certPrefix=<value optimized out>, keyPrefix=<value optimized out>, secmodName=<value optimized out>, flags=0) at nssinit.c:781 #8 0x00007fffef23da98 in Curl_nss_connect () from /usr/lib64/libcurl.so.4
Firefox is also not working right. In order to trick our version of firefox into using the system database properly (because it doesn't follow the guidelines set out on the mozilla wiki), I've added a pkcs12.txt file in my firefox profile directory which makes it load libnsssysinit.so, and I export NSS_DEFAULT_DB_TYPE=sql. This was working nicely with my own test build of NSS (although firefox definitely needs to be fixed before F-13 so that we don't need such hacks). But since updating to your build of NSS, it seems to have stopped remembering login passwords for me. The bar pops up asking if it should remember passwords, but clicking 'Remember' does nothing... the bar just stays there.
Program received signal SIGSEGV, Segmentation fault. __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:99 99 movlpd (%rdi), %xmm1 (gdb) up #1 0x00007fffed46323f in get_list ( stripped_parameters=0xa2bf20 " certPrefix='' keyPrefix='' secmod='' flags=readOnly updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDescription='' ", filename=0x0) at nsssysinit.c:255 255 if (userdb && !strcmp(filename, userdb)) (gdb) p filename $1 = 0x0 (gdb) p userdb $2 = 0xa2c010 "/home/dwmw2/.pki/nssdb" (gdb) up #2 NSS_ReturnModuleSpecData ( stripped_parameters=0xa2bf20 " certPrefix='' keyPrefix='' secmod='' flags=readOnly updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDescription='' ", filename=0x0) at nsssysinit.c:420 420 retString = get_list(filename, stripped); Turns out filename can be NULL, and it's crashing in the code I added. I didn't check for that -- it wasn't happening for me for some reason, and old the code was just using it regardless. But since it was only using it in the argument to PR_smprintf(), it didn't actually cause a crash -- it only caused "(null)" to appear in the result.
Oh, stupid dwmw2. I explicitly _set_ filename to NULL, if it matches the system database. This should fix at least the segfault: --- 546221.patch 26 Dec 2009 17:30:23 -0000 1.3 +++ 546221.patch 8 Jan 2010 10:35:28 -0000 @@ -31,7 +31,7 @@ diff -up nss-3.12.5/mozilla/security/nss + + if (sysdb && !strcmp(filename, sysdb)) + filename = NULL; -+ if (userdb && !strcmp(filename, userdb)) ++ else if (userdb && !strcmp(filename, userdb)) + filename = NULL; + if (userdb != NULL) { --- 547860.patch 7 Jan 2010 02:41:42 -0000 1.1 +++ 547860.patch 8 Jan 2010 10:39:05 -0000 @@ -69,7 +69,7 @@ diff -up nss-3.12.5/mozilla/security/nss #endif @@ -225,7 +255,8 @@ get_list(char *filename, char *stripped_ - if (userdb && !strcmp(filename, userdb)) + else if (userdb && !strcmp(filename, userdb)) filename = NULL; - if (userdb != NULL) { However, it still doesn't _work_ unless I disable nsssysinit: [dwmw2@macbook F-11]$ sudo setup-nsssysinit.sh on [sudo] password for dwmw2: [dwmw2@macbook F-11]$ python /usr/bin/bodhi --new --release F11 --file bodhi.template openconnect-2.20-1.fc11 -u dwmw2 Creating a new update for openconnect-2.20-1.fc11 Traceback (most recent call last): File "/usr/bin/bodhi", line 360, in <module> main() File "/usr/bin/bodhi", line 153, in main data = bodhi.save(**update_args) File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line 111, in save 'bugs': bugs, File "/usr/lib/python2.6/site-packages/fedora/client/baseclient.py", line 316, in send_request req_params = req_params, auth_params = auth_params) File "/usr/lib/python2.6/site-packages/fedora/client/proxyclient.py", line 275, in send_request request.perform() pycurl.error: (60, 'Peer certificate cannot be authenticated with known CA certificates') [dwmw2@macbook F-11]$ sudo setup-nsssysinit.sh off [dwmw2@macbook F-11]$ python /usr/bin/bodhi --new --release F11 --file bodhi.template openconnect-2.20-1.fc11 -u dwmw2 Creating a new update for openconnect-2.20-1.fc11 Password for dwmw2: Creating a new update for openconnect-2.20-1.fc11 Update successfully created ...
Hm, the problem in comment #17 goes away when I remove ~/.pki/nssdb/key4.db (and a new version of it gets created). When I put back the original version, the failure returns. [dwmw2@macbook nssdb]$ rm key4.db [dwmw2@macbook nssdb]$ curl https://clueless.aaisp.net.uk | head -1 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 101 812 0 812 0 0 153 0 --:--:-- 0:00:05 --:--:-- 11123 <HTML><HEAD><link rel="StyleSheet" href="internet.css" type="text/css"><TITLE>Network Administration</TITLE></HEAD><BODY BGCOLOR="#FFFFFF" onload="document.login.USERNAME.focus()"> [dwmw2@macbook nssdb]$ cp /home/dwmw2/.old-pki/nssdb/key4.db . [dwmw2@macbook nssdb]$ curl https://clueless.aaisp.net.uk | head -1 curl: (60) Peer certificate cannot be authenticated with known CA certificates This was all working yesterday, but even after I go back to my old version of NSS it still isn't working today. Confused...
(In reply to comment #15) > Firefox is also not working right. In order to trick our version of firefox > into using the system database properly (because it doesn't follow the > guidelines set out on the mozilla wiki), I've added a pkcs12.txt file in my > firefox profile directory which makes it load libnsssysinit.so, and I export > NSS_DEFAULT_DB_TYPE=sql. > > This was working nicely with my own test build of NSS (although firefox > definitely needs to be fixed before F-13 so that we don't need such hacks). But > since updating to your build of NSS, it seems to have stopped remembering login > passwords for me. The bar pops up asking if it should remember passwords, but > clicking 'Remember' does nothing... the bar just stays there. Filed as bug #553657
(In reply to comment #17) David, I submitted a variant of your changes as a patch for the segfault, see [Bug 553638]. Please review with Bob. Thanks.
Have you tested it against David's case? bob
Comment on attachment 382133 [details] patch v3 r- this can't possibly fix david's segv. The only line you changed from patch v2 is the: if (filename && 0) by adding another clause. if (filename && !userIsRoot() && 0). In both cases the code inside the if is never executed. bob
(In reply to comment #23) > (From update of attachment 382133 [details]) > r- this can't possibly fix david's segv. The only line you changed from patch > v2 is the: Bob, we have a separate bug for the SIGSEGV issue since it has already hit our users with ABRT. You're CC'd there for a while - bug #553638.
I'm now addressing now some comments Kamil had regarding my patch there. About testing, David was using bodhi to submit an update. "/usr/bin/bodhi --new --release F11 --file bodhi.template openconnect-2.20-1.fc11 -u dwmw2". I'll have to make some fake update to test it.
Comment on attachment 382133 [details] patch v3 r+ OK, this is a change I had asked for, but I had the review request mixed up with the segv issue. BTW this patch is probably better left for the upstream version (which needs to be collected and a mozilla bug opened for). bob
As for the completely broken initialization, following might be a viable check: $ curl -svo/dev/null https://bugzilla.redhat.com
(In reply to comment #26) > BTW this patch is probably better left for the upstream version (which needs to > be collected and a mozilla bug opened for). Please append me to CC list on the upstream bug in that case.
(In reply to comment #26) > BTW this patch is probably better left for the upstream version (which needs to > be collected and a mozilla bug opened for). Wait, this patch is needed now in Fedora as it is what enables root to add certificates the system database.
(In reply to comment #27) > As for the completely broken initialization, following might be a viable check: > $ curl -svo/dev/null https://bugzilla.redhat.com Thanks, I executed this check before and after applying the patches, see results at https://bugzilla.redhat.com/attachment.cgi?id=382739 My other test was, as root, to use certutil to add a certificate to the system database. certutil -L -d sql:/etc/pki/nssdb verified that it got added to the system db and not to /root/.pki/nssdb as had been the case that originally lead to this bug report.
Hm, I can't add certs as a normal user _either_. If I revert to 3.12.4-14 as shipped with Fedora 12, then this works: $ sudo setup-nssysinit on $ rm -rf ~/.pki/nssdb $ certutil -d sql:/etc/pki/nssdb -N $ certutil -d sql:/etc/pki/nssdb -E -i foo.pem But with newer NSS, starting from 3.12.5-1.fc12.2, it all fails. (Btw, every upgrade of nss-sysinit is causing the sysinit module to get disabled. On an upgrade, we run the new %post and then the old package's %postun. We should be looking at the numeric argument to the %post scripts to see if it's an upgrade, and do nothing if it is.)
I suspect that this part of the patch - if (userdb != NULL) { + /* Don't open root's user DB */ + if (userdb != NULL && !userIsRoot()) { is the cause of the problem.
(In reply to comment #32) > I suspect that this part of the patch > - if (userdb != NULL) { > + /* Don't open root's user DB */ > + if (userdb != NULL && !userIsRoot()) { > is the cause of the problem. Er, was that present in 3.12.5-1.fc12.2? I didn't think it was?
nss-3.12.5-7.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/nss-3.12.5-7.fc12
nss-3.12.5-7.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0685
nss-3.12.5-8.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/nss-3.12.5-8.fc12
nss-3.12.5-8.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1127
nss-3.12.5-8.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.