Closed Bug 374247 Opened 18 years ago Closed 15 years ago

modutil -disable command not disabling modules' slots


(NSS :: Libraries, defect, P2)



(Not tracked)



(Reporter: robert.bissett, Assigned: glenbeasley)



(Whiteboard: FIPS)


(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070216 Firefox/
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/
         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
Ever confirmed: true
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.

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.
Closed: 16 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.
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:
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:

(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.

Whiteboard: FIPS
Attached patch patch v1Splinter Review
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 
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
then built using trunk:

For cert8:
I confirmed that modutil -disable worked. I was no longer able to create a key using the sca6000 
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:
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

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:; previous revision: 1.24
Assignee: nelson → glen.beasley
Closed: 16 years ago15 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.