[ 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
