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

Ilia Vassilev (JIRA) issues at jboss.org
Wed May 30 10:20:02 EDT 2018


     [ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated WFLY-8431:
--------------------------------
    Git Pull Request: https://github.com/jboss/jboss-jaspi-api_spec/pull/4, https://github.com/picketbox/picketbox/pull/68  (was: https://github.com/jboss/jboss-jaspi-api_spec/pull/4)


> 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.5.0#75005)



More information about the jboss-jira mailing list