[jboss-jira] [JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code

[István Tóth (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13384141#comment-13384141 ] 

István Tóth commented on WFLY-8431:
-----------------------------------

I have attached a test case for the getFactory race.

1. Build the attached servlet into into a war (no config needed)
2. Deploy to  a wildfly instance
3. restart wildfly instance
4. Access the servlet

All displayed objects should be the same, but they are not.

The bug only triggers on the first access, and sometimes takes a few restarts to trigger.

> Race conditions in JASPIC registration code
> -------------------------------------------
>
>                 Key: WFLY-8431
>                 URL: https://issues.jboss.org/browse/WFLY-8431
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 10.1.0.Final
>         Environment: Centos 7 x86_64, with the included Java 8 environment
>            Reporter: István Tóth
>            Assignee: Darran Lofthouse
>         Attachments: GetFactoryTestCase.java
>
>
> javax.security.auth.message.config.AuthConfigFactory and 
> org.jboss.security.auth.message.config.JBossAuthConfigFactory 
> have race conditions.
> 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic.
> I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized)
> 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. 
> Nearly all methods of this class manipulate these, without any synchronization.
> In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a  negligible performance penalty. 
> The methods that modify the maps should also be made synchronized, or rewritten to use the  
> atomic ConcurrentHashMaps operations.
> A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)