Closed Bug 374247 Opened 14 years ago Closed 12 years ago
modutil -disable command not disabling modules' slots
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20070216 Firefox/188.8.131.52 Build Identifier: NSS 3.11.4 After installing a module "Sun Crypto Accelerator" on a machine with a hardware accelerator, the following modules/slots are found: ./gf/lib/modutil -dbdir /bobby/gf/domains/domain1/config -nocertdb -list Using database directory /bobby/gf/domains/domain1/config... Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. Sun Crypto Accelerator library name: /opt/SUNWconn/cryptov2/lib/libpkcs11.so slots: 3 slots attached status: loaded slot: test token: test slot: vca/0 Crypto Accel 2.0 token: vca/0 Crypto Accel 2.0 slot: Sun Crypto Softtoken token: Sun Software PKCS#11 softtoken ----------------------------------------------------------- After using the -disable command to disable the Sun Crypto Accelerator module, it is still enabled and the application server still prompts for passwords for the three slots when started. Reproducible: Always Steps to Reproduce: Tried disable command: --- begin --- # ./gf/lib/modutil -dbdir /bobby/gf/domains/domain1/config -nocertdb -disable "Sun Crypto Accelerator" WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q <enter>' to abort, or <enter> to continue: Using database directory /bobby/gf/domains/domain1/config... Slot "test" disabled. Slot "vca/0 Crypto Accel 2.0" disabled. Slot "Sun Crypto Softtoken" disabled. --- end --- Also tried this step and the disable one again: --- begin --- # ./gf/lib/modutil -dbdir /bobby/gf/domains/domain1/config -default "Sun Crypto Accelerator" -mechanisms FRIENDLY WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q <enter>' to abort, or <enter> to continue: Using database directory /bobby/gf/domains/domain1/config... Successfully changed defaults. --- end --- Actual Results: After trying to disable, the module still shows up in the module listing, and I am still prompted for passwords for the three slots when starting my app server: # asadmin start-domain [...] Please enter password for NSS slot Sun Software PKCS#11 softtoken> Please enter password for NSS slot vca/0 Crypto Accel 2.0> Please enter password for NSS slot test> [...] Expected Results: Expected to not be prompted for the passwords since the slots were disabled.
When this problem was first reported to me, it was reported that the user was trying to use one slot (the "Sun Crypto Softtoken" slot) in the "Sun Crypto Accelerator" module, but was trying to disable the other two slots to avoid password prompts for those slots. But the slots were not disabled, and NSS continued to prompt for each of them. I recommended filing a bug about that behavior. Now this bug reports a somewhat different problem, namely, that disabling the entire module does not work. The entire module and all its slots remain enabled. I suggested deleting the module to disable it. That may be an acceptable workaround for disabling the entire module, but obviously is not for disabling individual slots in a module. So I think disabling of modules and slots just isn't working.
OS: Other → Solaris
Hardware: Other → Sun
I rediscovered this bug while working on bug 444850. The patch for bug 444850 may or may not also fix this bug. Robert Bissett, are you still able to reproduce this? Are you willing to test a potential fix for this in 3.11.10 Beta ?
Depends on: 444850
Version: unspecified → 3.11.4
Hi Nelson, Sorry, I no longer have access to the systems we used to reproduce this issue. I'll see if I can find out who currently owns this within our app server group. Cheers, Bobby
After looking into this further, I discover that NSS has no way to actually disable entire modules. The "disabled" property is a property of slots ONLY. When you tell modutil to disable a module, and do not specify (by name) any slot in that module to be disabled, modutil disables all the slots in that module that it can find (that the module tells it about). However, some modules have dynamic slot naming. They may show different numbers of slots, and different names on those slots, from run to run. So, a user who uses modutil to disable a module (which really disables all the slots known at that instant) may find that later on, some slots in that module are not disabled, because those slots have names that did not exist at the time that modutil tried to disable all slots.
Summary: modutil -disable command not disabling modules → modutil -disable command not disabling modules' slots
I believe this will be fixed in NSS 3.11.10 by my checkin for bug 444850. Would be nice if the reporter or someone near him could confirm that it is fixed in 3.11.10, while 3.11.10 is still in Beta stage (as it is now).
Assignee: nobody → nelson
Component: Tools → Libraries
Priority: -- → P2
Target Milestone: --- → 3.11.10
Version: 3.11.4 → 3.4
I am marking this fixed in 3.11.10. If anyone finds that it does not appear to be fixed in their environment, please reopen this bug and add a comment here explaining how to reproduce the behavior you saw.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Thats fine with me (as the submitter) to mark it fixed. I've sent this info out to the people now in charge of our related projects, so if they see that there's still an issue they know where to go. Sorry I can't confirm the 444850 fix for you at this time.
disabling the slot or whole module doesnt seem to affect a list operation or applications utilising NSS. As requested informations are attached as follow: run 1: - adding a PKCS#11 module to a virgin secmod.db - disabling just a single slot - copying secmod.db - forcing apache to start, which in turn triggers mod_nss to enumerate to the "enabled" slots asking for login - result pkcs11 log generated by NSS, in addition a pkcs11 log by our library that shows in details calls hitting the library and ultimately the HSM run 2: - same as above but disabling the whole module instead of a single slot. result in both cases is that the user gets still prompted for PIN's on each available slot. "modutil -list... "also seems to ignore the disable flag (slot->disable == PR_TRUE)
In difference to the original report, this problem occours on the following environment: - RedHat Enterpise Linux 5.4 (kernel 2.6.18-164.el5 - NSS 3.12.4 - NSPR 4.8 - HSM - SafeNet ProtectServer Gold (CProv 3.33, FW 2.07)
As Bob has mentioned in the newsgroup, disabled slots don't disappear. They still appear in enumerations. But they should not "work". Hopefully, an examination of the attached files will tell us such things as: a) whether the "disabled" bits are really set or not, and b) whether operations that should be disallowed for disable slots are succeeding or not.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I've dumped the secmod.db databases and determined that the disable flag isn't being set. Looking at the code, this is because there is no string definition for the disable flag (this has been broken for a long time, at least 3.11 if not 3.10:(). The list of known strings can be found there: https://developer.mozilla.org/en/PKCS11_Module_Specs#NSS_Specific_Parameters_in_Module_Specs The field of interest is slotFlags This is a little out of date, SEED and Camilla have been added since. The fix is simple but painful: Add SECMOD_ARG_ENTRY(Disable, SECMOD_DISABLE_FLAG), to secmod_argSlotFlagTable in softoken/pk11pars.h (thus the pain). It might be possible to hack pk11wrap to support the flag when using sql database, but any prayer of supporting dbm will require the patch to softoken. Once that is in, we also need to verify that modutil actually writes the change out to the database. I did not see any such write in my debugging, but I didn't pursue that issue once I found the more primitive issue of the bit not being written out. bob
today I confirmed that "modutil -disable" did not work (had the same reported behavior) using NSS 3.11.10. and also in NSS 3.10.1 by testing old internal builds. Then I used bonsai to review the cvs history of the 24 versions of pk11pars.h and SECMOD_ARG_ENTRY(Disable, SECMOD_DISABLE_FLAG), has never existed in softoken/pk11pars.h. I actually looked for PK11_DISABLE_FLAG since a SECMOD_DISABLE_FLAG is not defined in softoken/secmodt.h I think the "modutil -disable" command has never worked. I modified softoken/pk11pars.h + SECMOD_ARG_ENTRY(Disable, PK11_DISABLE_FLAG), then built using trunk: For cert8: I confirmed that modutil -disable worked. I was no longer able to create a key using the sca6000 token certutil -S -n NewCert3 -s "O=BLA,C=US" -h "scaFIPS" -t ,,, -x -d . certutil: could not find the slot scaFIPS: The security card or token does not exist, needs to be initialized, or has been removed. then I did a modutil -enable, and successfully created key on my sca6000 token. For cert9: running: certutil -S -n NewCert3 -s "O=BLA,C=US" -h "scaFIPS" -t ,,, -x -d . was not a completely successful operation, but the key was created on the hardware token. I created bug 526674 for this separate issue. modutil -disable worked and modutil -enable worked like cert8 test case. I thought about modifying softoken/secmodt.h and creating SECMOD_DISABLE_FLAG, but ran of time today.
Attachment #410421 - Flags: review?(rrelyea)
Comment on attachment 410421 [details] [diff] [review] patch v1 r+ for SOFTOKEN_3_13 branch Init, fix the indentation bob
Attachment #410421 - Flags: review?(rrelyea) → review+
check into SOFTOKEN_3_13_BRANCH /cvsroot/mozilla/security/nss/lib/softoken/pk11pars.h,v <-- pk11pars.h new revision: 184.108.40.206; previous revision: 1.24 done
Assignee: nelson → glen.beasley
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: 3.11.10 → 3.13
I have tested the patch. That works for our environment. Let me know if additional testing would be required.
You need to log in before you can comment on or make changes to this bug.