db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunitha Kambhampati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1080) Connection reset when using security mechanism=EUSRIDPWD results in protocol error.
Date Fri, 10 Mar 2006 21:43:04 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]

Sunitha Kambhampati updated DERBY-1080:
---------------------------------------

    Attachment: derby1080.2.diff.txt
                derby1080.2.stat.txt

I am attaching a patch for Bryan's comments in
http://www.nabble.com/Re%3A-jira-Updated%3A-%28DERBY-1080%29-Connection-reset-when-using-security-mechanism%3DEUSRIDPWD-results-in-protocol-error.-p3293695.html

Thanks Bryan and Kathey for looking at this patch.  

This patch (Derby1080.2.diff.txt) makes the following change compared to previous Derby1080.diff.txt.

1) Reset of database.decryptedUserId and decryptedPassword is moved from DRDAConnThread to
Database.reset(). Note: that these 2 variables were not correctly reset for connection-reuse
which was causing the problem mentioned in this jira. This patch adds reset() method in Database
and resets the above 2 variable and also resets the variables related to security mechanism
only.

I talked to Kathey on IRC about this:
-- the above change fixes this particular problem in this issue.
-- But more investigation is required for database reset when connection pooling and transaction
pooling is done. 
-- File a jira so the reset cleanup can be done after investigation. 
Does this sound reasonable ?

2) I have reorganized the regression test and added lots of comments. I hope they are helpful
in understanding the expected results. 

3) Bryan asked"Lastly, would your test have been any different if you had used
ConnectionPoolDataSource.getPooledConnection(String user, String password)
rather than ConnectionPoolDataSource.getPooledConnection()? "

The result would be the same.  For eusridpwd case, the client sends the encrypted userid and
password sectkns as part of SECCHK. The protocol error was happening because we only read
the 2 sectkns if the database.decryptedUserId , database.decryptedPassword is null,  otherwise
we think we have already read this. Thus on a connection reset,if the decryptedUserId and
decryptedPassword are not reset, server assumes we have seen more SECTKN's and thus we throw
error too many codepoints.

Per the code: The userid/password passed in getPooledConnection will be the user and password
that is used. If userid and password is not  set in getPooledConnection, then the information
is retrieved from the ConnectionPoolDataSource. 

svn stat:

code change
M      java\drda\org\apache\derby\impl\drda\Database.java
M      java\drda\org\apache\derby\impl\drda\DRDAConnThread.java

test change
M      java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\testSecMec.java

master file for JCC2.4 driver and for IBM131, Sun JVM131,141,142,15.
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\testSecMec.out

master file for JCC2.6 driver and for IBM131, Sun JVM(versions 131,141,142,15)
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ver2.6\testSecMec.out

master file for JCC2.6 driver and for IBM (versions 141,142,15). Note these jvms support the
EUSRIDPWD security mechanism.
M     java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\ver2.6\testSecMec.out

master file for JCC2.4 driver and for IBM(versions 141,142,15). Note these jvms support the
EUSRIDPWD security mechanism.
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\testSecMec.out

master file for client driver and for IBM131, Sun JVM (versions 131,141,142,15)
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\testSecMec.out

master file for client driver and for IBM jvm (versions 141,142,15)
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\ibm14\testSecMec.out

Test ran ok with derbynetclientmats and derbynet with ibm142 on linux with known failures
in surtest and stress.multi. 
testSecMec.java was run with derby client, JCC2.4,JCC2.6 with ibm131,ibm141,ibm142,ibm15,sun
- jdk131,141,142,15 ok.

Please review this change.  Thanks.

> Connection reset when using security mechanism=EUSRIDPWD results in protocol error.
> -----------------------------------------------------------------------------------
>
>          Key: DERBY-1080
>          URL: http://issues.apache.org/jira/browse/DERBY-1080
>      Project: Derby
>         Type: Bug
>     Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2
>     Reporter: Sunitha Kambhampati
>     Assignee: Sunitha Kambhampati
>      Fix For: 10.2.0.0
>  Attachments: Derby1080.diff.txt, Derby1080.stat.txt, derby1080.2.diff.txt, derby1080.2.stat.txt
>
> if connection is reset,  the security mechanism related information for EUSRIDPWD is
not reset correctly and this leads to a protocol error. 

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


Mime
View raw message