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 Tue, 07 Mar 2006 18:30:39 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1080?page=all ]

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

    Attachment: Derby1080.diff.txt
                Derby1080.stat.txt

This patch Derby1080.diff.txt provides a fix to ensure that on a connection reset, we dont
throw too many codepoint error when reading SECTKN on a parseSECCHK when EUSRIDPWD security
mechanism  is used.

Overview:
DRDA spec, mentions this in section about connection pooling:
"Allows an application requester to reuse an existing network connection for a different
application once an application disconnects from the connection either by terminating or by
releasing the connection.
An application requester or application server at AGENT manager level 7 indicates the
support of flowing the EXCSAT, ACCSEC, SECCHK, and ACCRDB commands after a
successful commit or rollback to initialize a connection on behalf of a new application."

The DDM manual (pg54) for the ACCSEC command states that 
"The source server can send repeated ACCSEC commands when it wants to reuse a connection
for another application or transaction. The ACCSEC must be preceded by an EXCSAT, and
followed by a SECCHK and ACCRDB."

In the NetworkServer code:  we have comments in parseEXCSAT() which mentions about connection
resets 
where a EXCSAT is followed by an ACCSEC  (see DRDAConnThread.line 1222-1235)

Couple things to note:
1)On a parseACCSEC, on a RDBNAM , we can re-use the database object. Database stored information
for 
 the decryptedUserId and decryptedPassword which is used only for EUSRIDPWD security mechanism
case. 

2)ACCSEC is followed by SECCHK. On parseSECCHK, for the SECTKN codepoint we check if 
database.decryptedUserId and decryptedPassword is null and if so only then read the sectkn's
that 
are sent by client.  (see method parseSECCHK/case CodePoint.SECTKN)

3)On a re-use of a connection, since reset of the 2 variables in database does not happen,
on a 
SECCHK flow, we incorrectly throw an error that too many codepoints sent. The error can only
be seen when 
EUSRIDPWD security mechanism is used since only this requires the flow of SECTKN for encrypted
Userid and password
that is sent from the client.  

Fix: 
This patch fixes the case for EUSRIDPWD where this problem happens. For other security mechanisms
the fields decryptedUserId and decryptedPassword is not used. Reset decryptedUserId and decryptedPasword
on a parseACCSEC/RDBNAM to null.

svn stat:
M      java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
M      java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\testSecMec.java
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\testSecMec.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ver2.6\testSecMec.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\ver2.6\testSecMec.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\testSecMec.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\testSecMec.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\ibm14\testSecMec.out

I have a feeling we need to investigate more into this connection pooling (connection reset)
as well 
as transaction pooling. Maybe someone with more knowledge can comment on how transaction pooling

happens in network server. 

I ran derbyall on ibm142/linux ok with known failures(stress.multi and surtest).
I ran derbynet/testSecMec.java for both JCC and client driver on ibm131/ibm141/ibm142/ibm15
as well as sun jvms 131/142/15.

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