JDK-6524501 : inconsistency with PKCS#11 spec - 0-value flags in CK_SLOT_INFO struct returned by C_GetSlotInfo()
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 5.0u12,6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris,solaris_9
  • CPU: generic,sparc
  • Submitted: 2007-02-13
  • Updated: 2012-03-22
  • Resolved: 2011-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u10Fixed 7 b27Fixed OpenJDK6Fixed
Description
JCK tests verify that AuthProvider implementation throw LoginException if the login operation fails. 
sun.security.pkcs11.SunPKCS11.login throws NPE if null value passed to the method. This behaviour contradicts with the spec.

/net/archer/export5/re/jck/6a/nightly/qac/b06-2007-02-08/binaries/JCK-runtime-6a/classes javasoft.sqe.tests.api.java.security.AuthProvider.loginTests
----------out1:(144/9497)----------
Provider XMLDSig: Passed. Not AuthProvider. Skiped.
Provider SUN: Passed. Not AuthProvider. Skiped.
Provider SunJSSE: Passed. Not AuthProvider. Skiped.
Provider SunPCSC: Passed. Not AuthProvider. Skiped.
Provider SunJCE: Passed. Not AuthProvider. Skiped.
Provider SunSASL: Passed. Not AuthProvider. Skiped.
java.lang.NullPointerException
	at sun.security.pkcs11.SunPKCS11.login(SunPKCS11.java:1049)
	at javasoft.sqe.tests.api.java.security.AuthProvider.loginTests$1.run(loginTests.java:84)
	at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithTCKSM(SecurityTestRunner.java:278)
	at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithPermissions(SecurityTestRunner.java:235)
	at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithAllPermissions(SecurityTestRunner.java:157)
	at javasoft.sqe.jck.lib.AllPermissionSM.testRun(AllPermissionSM.java:86)
	at javasoft.sqe.jck.lib.AllPermissionSM.testRun(AllPermissionSM.java:111)
	at javasoft.sqe.tests.api.java.security.AuthProvider.loginTests.login001(loginTests.java:94)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:406)
	at javasoft.sqe.jck.lib.ProviderTest.invokeTestCase(ProviderTest.java:286)
	at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:195)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.jck.lib.ExecJCKTestSameJVMCmd$Version2Test.execute(ExecJCKTestSameJVMCmd.java:461)
	at com.sun.jck.lib.ExecJCKTestSameJVMCmd$StandardTest.run(ExecJCKTestSameJVMCmd.java:373)
	at com.sun.jck.lib.ExecJCKTestSameJVMCmd.execute(ExecJCKTestSameJVMCmd.java:241)
	at com.sun.jck.lib.ExecJCKTestSameJVMCmd.run(ExecJCKTestSameJVMCmd.java:142)
	at com.sun.javatest.agent.Agent$Task.executeCommand(Agent.java:822)
	at com.sun.javatest.agent.Agent$Task.execute(Agent.java:753)
	at com.sun.javatest.agent.Agent$Task.handleRequest(Agent.java:614)
	at com.sun.javatest.agent.Agent.handleRequestsUntilClosed(Agent.java:381)
	at com.sun.javatest.agent.Agent.access$000(Agent.java:41)
	at com.sun.javatest.agent.Agent$1.run(Agent.java:253)
	at java.lang.Thread.run(Thread.java:619)
login001: Failed. Test case throws exception: java.lang.NullPointerException
Provider XMLDSig: Passed. Not AuthProvider. Skiped.
Failed tests:
api/java_security/AuthProvider/ProviderTests.html#login[login001]
api/java_security/AuthProvider/ProviderTests.html#login[login002]
api/java_security/AuthProvider/ProviderTests.html#login[login003]
These tests failed only when running in Java plugin, the failure reproduced constantly.
First of all, run tests in Java plugin is a standard feature of JavaTest. JavaTest UG desribes all neccesary steps!
In addition, the failing tests can be run via JCK QA scripts:

1. ssh moonblade.russia.sun.com
2. mkdir -p /tmp/ProviderTests/tmp
3. mkdir -p /tmp/ProviderTests/workdir
4. mkdir -p /net/archer.russia.sun.com/export4/jck/tmp/ProviderTests/resultsdir
5. export TEMP=/tmp/ProviderTests/tmp
6. cd /net/archer.russia.sun.com/export4/jck/sqe-bin/QATools/bin
7. ./qa_latest -tc p002 -tcsuff _ProviderTests -testtype promoted -mailto <e-mail_address> -iu api/java_security/AuthProvider/ProviderTests.html -display moonblade.russia.sun.com:0.0 -workdir /tmp/ProviderTests/workdir -resultsdir /net/archer.russia.sun.com/export4/jck/tmp/ProviderTests/resultsdir
Comments
EVALUATION Solaris softtoken team is hesitant about changing the return value, thus SunPKCS11 provider would have to make necessary adjustments. Although Solaris softtoken impl can still perform some crypto operations, e.g. RSA keypair generations, existing SunPKCS11 provider impl has dependency on token be present and would generally not able to function. Given the rarity of such accounts, the fix is to disable SunPKCS11 provider when keystore is unaccessible.
09-08-2007
EVALUATION As Yu-ching Peng stated, the test account has a problem. Given the investigation she and I have done, it is clear that the test user does not have access to it's home directory and the system is operating as expected.. Without access to the home directory, softtoken is not operating at full functionality, it can still provide crypto services, but not perform token object support. Given this is a conformance test, it is within spec in this case to report the provider as not properly functioning..
30-07-2007
EVALUATION Re-assigning it to solaris softtoken category since it's agreed that the root cause is due to an inconsistency with PKCS#11 spec. Also update the synopsis accordingly.
27-07-2007
EVALUATION I can only reproduce the problem with a given test account. After further troubleshooting, it appears that Sun softtoken impl does not fully work when running under that particular account. For example, if you run the following command line: -------------------------------------------------------------------------- $ cryptoadm list -v provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so Number of slots: 1 Slot #1 Description: Sun Crypto Softtoken Manufacturer: Sun Microsystems, Inc. PKCS#11 Version: 2.11 Hardware Version: 0.0 Firmware Version: 0.0 Token Present: False Slot Flags: /usr/lib/security/$ISA/pkcs11_softtoken.so: failed to retrieve the mechanism list. -------------------------------------------------------------------------- I tried to inspect the default keystore used by Sun softtoken impl with pktool but the "<user home>/.sunw/pkcs11_softtoken" directory is not there. Nor do I get expected behavior when running "pktool setpin" command. Thus, this suggests that the problem is in the account setup and not Sun's PKCS#11 provider. Changing the status to Incomplete/Other until further confirmation from the submitter.
01-06-2007
EVALUATION It's unclear why these tests only fail when running in Java Plugin. Thus, please provide detailed information on how these tests are executed. Again, marking this w/ "incomplete - need more info".
21-03-2007
EVALUATION I don't observe any JCK test failure using both the official jdk6 b105 and my own jdk7 builds on Solaris 10. The JCK tests are executed as: ----------------- /java/re/jdk/6.0/promoted/fcs/b105/binaries/solaris-sparc/bin/java -showversion -classpath /java/re/jck/6a/nightly/qac/b06-2007-02-08/binaries/JCK-runtime-6a/classes:/java/re/jck/6a/nightly/qac/b06-2007-02-08/binaries/JCK-runtime-6a/lib/javatest.jar javasoft.sqe.tests.api.java.security.AuthProvider.loginTests ----------------- The output looks fine too. Sample messages: Provider XMLDSig: Passed. Not AuthProvider. Skiped. Provider SUN: Passed. Not AuthProvider. Skiped. ... Provider SunSASL: Passed. Not AuthProvider. Skiped. Provider SunPKCS11-Solaris: Passed. OKAY Provider SunRsaSign: Passed. Not AuthProvider. Skiped. Provider SunJGSS: Passed. Not AuthProvider. Skiped. So, I am marking this bug "incomplete" for now so that submitter can verify if this bug can still be reproduced on his end.
16-03-2007