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/03/07 19:30:39 UTC
[jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
[ 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
Re: [jira] Updated: (DERBY-1080) Connection reset when using security
mechanism=EUSRIDPWD results in protocol error.
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Sunitha Kambhampati (JIRA) wrote:
> Attachment: Derby1080.diff.txt
Hi Sunitha,
I took a very quick look at your patch, and wanted to offer the following feedback:
1) Resetting database state information when re-using a database object seems
like a reasonable behavior to me. I think it would be nice to use the same
overall naming conventions and techniques that Deepa established in DERBY-1002,
so maybe you might want to investigate whether your new code should go into
a database.reset() method rather than being open-coded in DRDAConnThread.
2) A couple more comments in the code in the "try" block in testSecMecWithConnPooling()
would be nice, to make it more clear as to why you are re-using the connection and
what the expected result is. In particular, I found myself unable to explain why
some of the master files show this test succeeding, and some of the master files
show it getting an exception, so some comments would help me understand why the
various master files have the contents that they do.
3) Lastly, would your test have been any different if you had used
ConnectionPoolDataSource.getPooledConnection(String user, String password)
rather than ConnectionPoolDataSource.getPooledConnection()? I guess I don't
really understand how the user's identification information is intended to be
passed around when using pooled connections, and the JDBC javadocs did not
provide an obvious answer.
thanks,
bryan