You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org> on 2006/09/07 18:35:23 UTC
[jira] Updated: (DERBY-1675) Network Server should not send to
client that it supports EUSRIDPWD when running against Sun JVM
[ http://issues.apache.org/jira/browse/DERBY-1675?page=all ]
Sunitha Kambhampati updated DERBY-1675:
---------------------------------------
Attachment: derby1675.stat.txt
derby1675.diff.txt
EUSRIDPWD support depends on the JCE available in the classpath of the server
This patch(derby1675.diff.txt) does the following
1. Add code to check if server jvm can support EUSRIDPWD.
2. Throw an error if the derby.drda.securityMechanism is set to ENCRYPTED_USER_AND_PASSWORD_SECURITY
and if the server jvm cannot support EUSRIDPWD.
3. Server sends the client the list of supported security mechanisms as part of ACCSECRD. Now, the server will correctly only send EUSRIDPWD as an option if the running server can support this security mechanism.
Test related changes:
Changes were made to testProtocol.java and a new method readSecMecAndSECCHKCD is added to TestProto to read the SECMEC and SECCHKCD values. Note, that with ibm142 and ibm15 jvms that support eusridpwd, the SECMEC value 9 (eusridpwd) will be sent as part of the ACCSECRD response. But for the jvms that dont support the eusridpwd, the SECMEC value of 9 wont be sent. The new method readSecMecAndSECCHKCD takes
care of printing out the SECMEC values that are sent by the server - this results in the need for a new master file for the jvm that support eusridpwd and the jvm that cannot support it. A new master file has been added for ibm14.
Tests for codepath that covers #2 is already present in testSecMec.java. This results in themaster updates for the jvms that do not support eusridpwd for the case where server is started with
derby..drda.securityMechanism=ENCRYPTED_USER_AND_PASSWORD_SECURITY.
derbyall ran ok on ibm142/linux with two known intermittent failures(NSInSameJVM and DerbyNetAutoStart)
I ran testSecMec on win2k/t40laptop/ on ibm jvm 131,142,15 as well as sun jvm 131,142,15. Also have updated masters for jcc versions 2.4,2.6,2.8.
Can someone please review this change.
Thanks.
> Network Server should not send to client that it supports EUSRIDPWD when running against Sun JVM
> ------------------------------------------------------------------------------------------------
>
> Key: DERBY-1675
> URL: http://issues.apache.org/jira/browse/DERBY-1675
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0, 10.2.1.0
> Reporter: Sunitha Kambhampati
> Assigned To: Sunitha Kambhampati
> Priority: Minor
> Attachments: derby1675.diff.txt, derby1675.stat.txt
>
>
> As part of ACCSECRD, if the server does not accept the security mechanism sent by the client, the server will send a list of security mechanism that it supports. Currently even when the server is running with sun jvm, it will still send EUSRIDPWD as a sec mec that it supports, which is incorrect. The server should test if it can support EUSRIDPWD dynamically and if it does, only then send EURRIDPWD as an option that it supports.
> see DRDAConnThread.writeACCSECRD(int)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira