[Design of Security on JBoss] - Concurrency bug in JaasSecurityManager
by Cyberax
This is a cross-post from user forum (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=95622).
I've found a VERY curious concurrency bug in JaasSecurityManager. I'm using custom login modules and custom principal and a custom SecurityInterceptor for JNDI lookups, this interceptor checks .
My DefaultCacheTimeout value was set to 0 (I wanted to turn off authentication cache).
My application (remote Swing client) worked fine as long as there was only one thread doing JNDI lookups. But sometimes a second application threw exception during JNDI authorization , it turned out that authenticated Subject had an empty role set. But this is impossible, because my Subjects always have at least one role.
After few hours of debugging I've found the problem: my custom login module removes its Subject roles during the logout() method. I've found that this module is called by JaasSecurityManager$DomainInfo.destroy. And that's a bug.
Suppose we have two threads:
Code:
| Thread 1: Thread 2 (some time after Thread1):
| 1. 'User1' authentication 1. 'User1' logs in.
| 2. 'User1' is added to auth cache 2. Auth cache entry has expired.
| 3. Doing some lengthy operation 3. Calling .logout() on stale entry
| 4. Checking roles of User1 - WILL FAIL, another thread has called logout()!
|
This problem may be not evident with the stock JBoss login modules, because their logout() methods do not remove subject's roles.
Proposed fixes:
1. Use deep cloning. That way threads 1 and 2 doesn't share any data, thus no problem.
2. Use acquire/release semantics in conjunction with SecurityAssociation.
3. Remove logout() from DomainInfo.destroy.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992393#3992393
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992393
18 years, 1 month
[Design of JBoss Remoting, Unified Invokers] - Exception propagation using HTTP servlet transport on 1.4.4
by Cyberax
There's a bug in ServletServerInvoker in 1.4.4 version of remoting.
'processRequest' methods do not support propagation of exceptions to remote clients.
This code:
| try
| {
| // call transport on the subclass, get the result to handback
| invocationResponse = invoke(invocationRequest);
| }
| catch(Throwable ex)
| {
| log.debug("Error thrown calling invoke on server invoker.", ex);
| invocationResponse = ex;
| isError = true;
| }
|
| //Start with response code of 204 (no content), then if is a return from handler, change to 200 (ok)
| int status = 204;
| if(invocationResponse != null)
| {
| if(isError)
| {
| response.sendError(500, "Error occurred processing invocation request. ");
| }
| else
| {
| status = 200;
| }
| }
|
sends "500 Server Error" message in response body to client. Client then tries to unmarshal this message using ObjectInputStream and fails.
The simple fix is:
| try
| {
| // call transport on the subclass, get the result to handback
| invocationResponse = invoke(invocationRequest);
| }
| catch(Throwable ex)
| {
| log.debug("Error thrown calling invoke on server invoker.", ex);
| invocationResponse = ex;
|
| String sessionId=null;
| if (invocationRequest instanceof InvocationRequest)
| sessionId=((InvocationRequest)invocationRequest).getSessionId();
| invocationResponse=new InvocationResponse(sessionId,ex,true,null);
| //isError = true;
| }
|
It seems to be working for me.
Should I create JIRA bug for this issue?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992391#3992391
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992391
18 years, 1 month
[Design of POJO Server] - Re: ProfileService kickoff
by scott.stark＠jboss.org
"weston.price(a)jboss.com" wrote :
| From a root deployment (initial deployment) the profile service has to know about what gets deployed and the metadata that gets generated as result, or at the very least, it's Management DD. It does this via the deployment chain as you talked about. The results of the initial deployment are persisted to the repository. Diffs can begin at this point, effectively the deployment is versioned.
|
| I think I was hung up more on the 'who starts the chain' more than I was what happens as a result.
|
| So, based on this design, there is no concept of a JBoss instance existing without a ProfileService, they are effectively one and the same in terms of the 'client view'. The ProfileService really takes over what the old JMX system used to provide but with a ton of more features (versioning, dynamic lifecycle including a STOP, etc).
|
| Let me know if I am on the right track.
|
The profile service plugs into the long standing ServerImpl bootstrap mechanism, so to some extent its replacable. With the update to all of the deployers, there is an extended contract on how deployments are brought into the server that obsoletes the old scanners, but they could be ported over in place of the profile service.
Certainly all of the new features we are working on now are quality of service issues that can be disabled and you still have a functional server. We do want a full featured profile service as the default replacement for the old jmx deployment mechanism, so yes, there is no interesting jboss server without a profile service.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992380#3992380
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992380
18 years, 1 month
[Design of POJO Server] - Re: ProfileService kickoff
by weston.price＠jboss.com
OK, I think I have a better grasp on this now.
>From a root deployment (initial deployment) the profile service has to know about what gets deployed and the metadata that gets generated as result, or at the very least, it's Management DD. It does this via the deployment chain as you talked about. The results of the initial deployment are persisted to the repository. Diffs can begin at this point, effectively the deployment is versioned.
I think I was hung up more on the 'who starts the chain' more than I was what happens as a result.
So, based on this design, there is no concept of a JBoss instance existing without a ProfileService, they are effectively one and the same in terms of the 'client view'. The ProfileService really takes over what the old JMX system used to provide but with a ton of more features (versioning, dynamic lifecycle including a STOP, etc).
Let me know if I am on the right track.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992370#3992370
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992370
18 years, 1 month