[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code
by István Tóth (JIRA)
[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ]
István Tóth commented on WFLY-8431:
-----------------------------------
The link to the getFactory() fix PR is
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.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8868) per application Expressions
by Juergen Weber (JIRA)
[ https://issues.jboss.org/browse/WFLY-8868?page=com.atlassian.jira.plugin.... ]
Juergen Weber updated WFLY-8868:
--------------------------------
Description:
Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
This should be enhanced to support application scoped expressions:
${this:aProperty}
It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
Then you could deploy the same Message Driven Bean multiple times with a different name:
myMDB1.ear
myMDB2.ear
having
<activation-config-property-value>${this:queuename}</activation-config-property-value>
and define
<application-properties>
<application name="myMDB_DEV_QUEUE_1.ear">
<property name="queuename" value="DEV_QUEUE_1"/>
</application>
<application name="myMDB_DEV_QUEUE_2.ear">
<property name="queuename" value="DEV_QUEUE_2"/>
</application>
</application-properties>
whereas for production the queuename properties would be different.
[1] https://docs.jboss.org/author/display/WFLY10/Expressions
was:
Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
This should be enhanced to support application scoped expressions:
{{${this:aProperty}}}
It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
Then you could deploy the same Message Driven Bean multiple times with a different name:
myMDB1.ear
myMDB2.ear
having
{{<activation-config-property-value>${this:queuename}</activation-config-property-value>}}
and define
{{<application-properties>
<application name="myMDB_DEV_QUEUE_1.ear">
<property name="queuename" value="DEV_QUEUE_1"/>
</application>
<application name="myMDB_DEV_QUEUE_2.ear">
<property name="queuename" value="DEV_QUEUE_2"/>
</application>}}
</application-properties>
whereas for production the queuename properties would be different.
[1] https://docs.jboss.org/author/display/WFLY10/Expressions
> per application Expressions
> ---------------------------
>
> Key: WFLY-8868
> URL: https://issues.jboss.org/browse/WFLY-8868
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Juergen Weber
> Assignee: Jason Greene
>
> Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
> This should be enhanced to support application scoped expressions:
> ${this:aProperty}
> It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
> Then you could deploy the same Message Driven Bean multiple times with a different name:
> myMDB1.ear
> myMDB2.ear
> having
> <activation-config-property-value>${this:queuename}</activation-config-property-value>
> and define
> <application-properties>
> <application name="myMDB_DEV_QUEUE_1.ear">
> <property name="queuename" value="DEV_QUEUE_1"/>
> </application>
> <application name="myMDB_DEV_QUEUE_2.ear">
> <property name="queuename" value="DEV_QUEUE_2"/>
> </application>
> </application-properties>
> whereas for production the queuename properties would be different.
> [1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8868) per application Expressions
by Juergen Weber (JIRA)
Juergen Weber created WFLY-8868:
-----------------------------------
Summary: per application Expressions
Key: WFLY-8868
URL: https://issues.jboss.org/browse/WFLY-8868
Project: WildFly
Issue Type: Feature Request
Reporter: Juergen Weber
Assignee: Jason Greene
Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
This should be enhanced to support application scoped expressions:
{{${this:aProperty}}}
It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
Then you could deploy the same Message Driven Bean multiple times with a different name:
myMDB1.ear
myMDB2.ear
having
{{<activation-config-property-value>${this:queuename}</activation-config-property-value>}}
and define
{{<application-properties>
<application name="myMDB_DEV_QUEUE_1.ear">
<property name="queuename" value="DEV_QUEUE_1"/>
</application>
<application name="myMDB_DEV_QUEUE_2.ear">
<property name="queuename" value="DEV_QUEUE_2"/>
</application>}}
</application-properties>
whereas for production the queuename properties would be different.
[1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1338:
------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1195079|https://bugzilla.redhat.com/show_bug.cgi?id=1195079] from MODIFIED to ON_QA
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1338
> URL: https://issues.jboss.org/browse/JBJCA-1338
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.2.7.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-8458:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1436390|https://bugzilla.redhat.com/show_bug.cgi?id=1436390] from MODIFIED to ON_QA
> NPE when MBean does not have no-arg constructor
> -----------------------------------------------
>
> Key: WFLY-8458
> URL: https://issues.jboss.org/browse/WFLY-8458
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Server
> Affects Versions: 11.0.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 11.0.0.Beta1
>
>
> NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE
> {code}
> 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated
> at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131)
> ... 9 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1168) Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1168?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek commented on ELY-1168:
-----------------------------------
[~soul2zimate]
Keep on mind that problem is when you use "entry-type" without value.
> Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass.
> ----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1168
> URL: https://issues.jboss.org/browse/ELY-1168
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Chao Wang
>
> Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass.
> It seems to be little confusing. I prefer error message rather than success.
> Reason why it works now is because as a value is used default value for entry-type.
> *How to reproduce*
> {code}
> java -jar ./bin/wildfly-elytron-tool.jar credential-store --add secret_alias --create -l store123.jceks --password pass123 -x test -n
> Alias "secret_alias" has been successfully stored
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8760) get method of ModuleClassLoaderLocator requires createClassLoader permission
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8760?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas commented on WFLY-8760:
------------------------------------
[~gaol] I am able reproduce it with Servlet which calls:
{code}
import org.jboss.security.mapping.MappingContext;
import org.jboss.security.mapping.MappingManager;
import org.jboss.security.mapping.MappingType;
import org.picketbox.factories.SecurityFactory;
...
MappingManager mm = SecurityFactory.getMappingManager(securityDomainName);
MappingContext<Object> mc = mm.getMappingContext(MappingType.ATTRIBUTE.name());
...
{code}
Then following AccessControlException is thrown:
{code}
ERROR [io.undertow.request] (default task-9) UT005023: Exception handling request to /844252ce-02ae-4a7a-b414-4be69116984f/protected/LdapAttributeMappingProviderServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createClassLoader")" in code source "(vfs:/content/844252ce-02ae-4a7a-b414-4be69116984f.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.844252ce-02ae-4a7a-b414-4be69116984f.war" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
at org.wildfly.security.manager.WildFlySecurityManager.checkCreateClassLoader(WildFlySecurityManager.java:308)
at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274)
at java.lang.ClassLoader.<init>(ClassLoader.java:335)
at java.security.SecureClassLoader.<init>(SecureClassLoader.java:99)
at org.jboss.as.security.plugins.ModuleClassLoaderLocator$CombinedClassLoader.<init>(ModuleClassLoaderLocator.java:82)
at org.jboss.as.security.plugins.ModuleClassLoaderLocator.get(ModuleClassLoaderLocator.java:72)
at org.jboss.security.plugins.mapping.JBossMappingManager.generateMappingContext(JBossMappingManager.java:111)
at org.jboss.security.plugins.mapping.JBossMappingManager.getMappingContext(JBossMappingManager.java:74)
...
{code}
> get method of ModuleClassLoaderLocator requires createClassLoader permission
> ----------------------------------------------------------------------------
>
> Key: WFLY-8760
> URL: https://issues.jboss.org/browse/WFLY-8760
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Lin Gao
> Priority: Critical
>
> There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of WFLY-7412 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission.
> That means:
> * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission)
> ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator.
> * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8760) get method of ModuleClassLoaderLocator requires createClassLoader permission
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-8760?page=com.atlassian.jira.plugin.... ]
Lin Gao reassigned WFLY-8760:
-----------------------------
Assignee: Lin Gao (was: Darran Lofthouse)
> get method of ModuleClassLoaderLocator requires createClassLoader permission
> ----------------------------------------------------------------------------
>
> Key: WFLY-8760
> URL: https://issues.jboss.org/browse/WFLY-8760
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Lin Gao
> Priority: Critical
>
> There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of WFLY-7412 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission.
> That means:
> * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission)
> ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator.
> * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month