Bugs item #630616, was opened at 2002-10-29 10:02
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=630616&group_id=22866
Category: JBossCX
Group: v3.0 Rabbit Hole
>Status: Open
>Resolution: Accepted
Priority: 8
Submitted By: Peter Antman (pra)
Assigned to: Scott M Stark (starksm)
Summary: Subject empty of credentials
Initial Comment:
During certain conditions when two thread truly
concurrent are using a connections resource the subject
will magically get emptyed on its private credentials
before reaching mcf.createManagedConnection or its
matchmethod. This has happended for me with both the
LocalManagedConnectionFactory class and the JMS ra
equiv.
To mee its seems as if a JAAS logout done in one thread
ConfiguredIdentityLoginModule.logout in one thread
seems to affect the Subject in another thread.
There are two logfiles showing this condition. One time
with Thread-74 losing this battle, another with
Thread-75 losing. Subject.toString has been added to
the exception thrown from LMCF where it is obvoius that
the private credentials that once where there is gone
when needed.
This is on cvs for the 3.0 branch. On a dual CPU RedHat
7.3 and with 1.4.1-beta-b14 mixed mode.
//Peter
----------------------------------------------------------------------
>Comment By: Scott M Stark (starksm)
Date: 2002-10-30 00:55
Message:
Logged In: YES
user_id=175228
Actually there is still a problem even after this change. This
is due to the use of the Subject instance which is a reference
a data member of the security cache instance. The problem
is that even if only one thread updates the auth cache, a
reference may exist to a previous entry's internal state due to
the reference to the Subject.
I am looking at a copy on flush of the Subject to preserve the
authenticated state for the duration of the reference. I'm in the
process of implementing and testing this approach.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-10-29 21:01
Message:
Logged In: YES
user_id=175228
I think I see the problem. Although authentication can
proceed simultaneously for two threads, the cache is
principal based and two threads attempting to authenticate
the same principal will result in a race to see which thread
populates the cache. Right now the syncrhronization is too
fine and first one thread puts its login result into the cache
and this is overwritten by the second. Its the same info, but
the act of the second thread overwriting the first invalidates
the Subject contents of the first thread because the removal
of the cache entry invokes logout on the login modules used
to build the cache entry. I have made the synchronization
coarser to only allow a single thread to be active in
authentication to prevent this. Retest against the latest
JaasSecurityManager change.
----------------------------------------------------------------------
Comment By: Peter Antman (pra)
Date: 2002-10-29 13:37
Message:
Logged In: YES
user_id=84651
Here are some more input. The exceptions seems to have to do
with conections pool (idle)timeout. I happend almost exactly
30 minutes after the server was started. The stuff is run
from a timer thread and has run several time with succes
before this happens.
As far as my debugging can tell me, what happend is that one
thread is actually going into another threads
ConfiguredIdentityLoginModule and removes the private
credentials of that subject, which is the no longer usefull.
Here follows a comentet logging of the event (with some
logging stuff added to JBoss - the complete logg is also
appended).
Two thread want to have a connection, Thread-78 and
Thread-79.
Here is sort of the first thing that happens in this chain:
2002-10-29 21:57:59,983 1849263 TRACE
[org.jboss.resource.connectionmanager.CachedConnectionManager]
(Thread-78:NewsGuarderManager) old stack for key:
se.tim.in.kernel.app.server.NewsGuarderManagerImpl@1ab3cda
2002-10-29 21:57:59,983 1849263 TRACE
[org.jboss.resource.connectionmanager.CachedConnectionManager]
(Thread-79:NewsGuarderManager) old stack for key:
se.tim.in.kernel.app.server.NewsGuarderManagerImpl@344422
Thread-78 by some reason I don't know starts by removing the
creds during a logout:
2002-10-29 21:57:59,985 1849265 TRACE
[org.jboss.resource.security.AbstractPasswordCredentialLoginModule]
(Thread-78:NewsGuarderManager) Removing credentials from
subject in lm
(org.jboss.resource.security.ConfiguredIdentityLoginModule@c70f32)
�rende:
Principal: pra
Privata kreditiv:
javax.resource.spi.security.PasswordCredential@59905d80
Then an initialization is started for both threads:
2002-10-29 21:57:59,986 1849266 TRACE
[org.jboss.resource.security.ConfiguredIdentityLoginModule]
(Thread-78:NewsGuarderManager) initialize
2002-10-29 21:57:59,986 1849266 TRACE
[org.jboss.resource.security.ConfiguredIdentityLoginModule]
(Thread-79:NewsGuarderManager) initialize
Thread-78 does a login:
2002-10-29 21:57:59,987 1849267 TRACE
[org.jboss.resource.security.ConfiguredIdentityLoginModule]
(Thread-78:NewsGuarderManager) login called on lm
org.jboss.resource.security.ConfiguredIdentityLoginModule@584e97
Observe the extra logging info. This is done against
ConfiguredIdentityLoginModule@584e97, which holds its
subject.
Thread-79 then does its login:
2002-10-29 21:57:59,987 1849267 TRACE
[org.jboss.resource.security.ConfiguredIdentityLoginModule]
(Thread-79:NewsGuarderManager) login called on lm
org.jboss.resource.security.ConfiguredIdentityLoginModule@d733ca
We then get to know that Thread-78 found a nice subject:
2002-10-29 21:57:59,988 1849268 TRACE
[org.jboss.resource.connectionmanager.LocalTxConnectionManager]
(Thread-78:NewsGuarderManager) subject: �rende:
Principal: pra
Privata kreditiv:
javax.resource.spi.security.PasswordCredential@59905d80
Then it is getting interesting. Thread-78 tries to continue
with getting its connection:
2002-10-29 21:57:59,988 1849268 INFO
[org.jboss.resource.connectionmanager.LocalTxConnectionManager]
(Thread-78:NewsGuarderManager) getManagedConnection
returning unassociated connection
But before this reached the MCF, Thread-79 is doing some
work, and what work then:
2002-10-29 21:57:59,988 1849268 TRACE
[org.jboss.resource.security.AbstractPasswordCredentialLoginModule]
(Thread-79:NewsGuarderManager) Removing credentials from
subject in lm
(org.jboss.resource.security.ConfiguredIdentityLoginModule@584e97)
�rende:
Principal: pra
Privata kreditiv:
javax.resource.spi.security.PasswordCredential@59905d80
Now a logout is obviously done in Thread-79. But hay,
against which LoginModule: the one Thread-78 is using!! Not
against its own, namely
ConfiguredIdentityLoginModule@d733ca.
When Thread-78 reaches the mcf which is trying to the the
credentials from the Subject, Thread-79 has removed them!
This must a bugg, but I can't find my way around the code to
locate what is actually making these logout calls to the
LoginModule (and the wrong one).
//Peter
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=630616&group_id=22866
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
