[JBoss JIRA] (ELY-1428) Elytron provider has to be installed manually in some client scenarios
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1428?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1428:
------------------------------
Description:
Trying to configure ejb client 2-way TLS authentication with Elytron. I can't configure client private key without use of programatically registering Elytron provider.
{noformat}
Security.addProvider(new WildFlyElytronProvider());
{noformat}
Specifying this in {{wildfly-config.xml}} doesn't help:
{noformat}
<providers>
<use-service-loader/>
</providers>
{noformat}
Example of {{wildfly-config.xml}} where I need this when using it with EJB client:
{code:xml}
<configuration>
<authentication-client xmlns="urn:elytron:1.0">
<authentication-rules>
<rule use-configuration="default"/>
</authentication-rules>
<authentication-configurations>
<configuration name="default">
<credentials>
<key-store-reference key-store-name="client-keystore" alias="joe">
<key-store-clear-password password="abcdef"/>
</key-store-reference>
</credentials>
</configuration>
</authentication-configurations>
<key-stores>
<key-store name="client-keystore" type="JKS">
<file name="${keystore.path:src/main/resources/client.keystore}"/>
<key-store-clear-password password="abcdef"/>
</key-store>
<key-store name="client-truststore" type="JKS">
<file name="${truststore.path:src/main/resources/client.truststore}"/>
</key-store>
</key-stores>
<ssl-contexts>
<ssl-context name="client-ssl-context">
<trust-store key-store-name="client-truststore"/>
<key-store-ssl-certificate key-store-name="client-keystore" alias="joe">
<key-store-clear-password password="abcdef"/>
</key-store-ssl-certificate>
</ssl-context>
</ssl-contexts>
<ssl-context-rules>
<rule use-ssl-context="client-ssl-context"/>
</ssl-context-rules>
</authentication-client>
</configuration>
{code}
Without installing the Elytron provider, the client will fail with this error:
{noformat}
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:49)
at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:282)
at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:81)
at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:89)
at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:87)
at org.jboss.ejb.client.EJBClientInvocationContext.<init>(EJBClientInvocationContext.java:87)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:154)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
at com.sun.proxy.$Proxy2.hello(Unknown Source)
at client.Client.main(Client.java:21)
Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
at java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
... 10 more
Caused by: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1410)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$28(ElytronXmlParser.java:952)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$36(ElytronXmlParser.java:997)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$21(ElytronXmlParser.java:733)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$25(ElytronXmlParser.java:781)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$10(ElytronXmlParser.java:613)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$11(ElytronXmlParser.java:639)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:337)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:214)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:175)
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
... 12 more
Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear"
at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121)
at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:75)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1376)
... 24 more
{noformat}
Using credential-store-reference clear-text cause similar error.
There is example of clear passwords which works, so it will be problem of this specific elements:
{code:xml}
<authentication-client xmlns="urn:elytron:1.0">
<authentication-rules>
<rule use-configuration="default"/>
</authentication-rules>
<authentication-configurations>
<configuration name="default">
<sasl-mechanism-selector selector="DIGEST-MD5"/>
<set-user-name name="joe"/>
<credentials>
<clear-password password="joeIsAwesome2013!"/>
</credentials>
</configuration>
</authentication-configurations>
</authentication-client>
{code}
was:
Not sure what are the exact scenarios when this is required, but in some cases, when using a client with {{wildfly-client.xml}}, I have to add the Elytron security provider manually using this:
{noformat}
Security.addProvider(new WildFlyElytronProvider());
{noformat}
Specifying this in {{wildfly-config.xml}} doesn't help:
{noformat}
<providers>
<use-service-loader/>
</providers>
{noformat}
Example of {{wildfly-config.xml}} where I need this when using it with EJB client:
{noformat}
<configuration>
<authentication-client xmlns="urn:elytron:1.0">
<authentication-rules>
<rule use-configuration="default"/>
</authentication-rules>
<authentication-configurations>
<configuration name="default">
<credentials>
<key-store-reference key-store-name="client-keystore" alias="joe">
<key-store-clear-password password="abcdef"/>
</key-store-reference>
</credentials>
</configuration>
</authentication-configurations>
<key-stores>
<key-store name="client-keystore" type="JKS">
<file name="${keystore.path:src/main/resources/client.keystore}"/>
<key-store-clear-password password="abcdef"/>
</key-store>
<key-store name="client-truststore" type="JKS">
<file name="${truststore.path:src/main/resources/client.truststore}"/>
</key-store>
</key-stores>
<ssl-contexts>
<ssl-context name="client-ssl-context">
<trust-store key-store-name="client-truststore"/>
<key-store-ssl-certificate key-store-name="client-keystore" alias="joe">
<key-store-clear-password password="abcdef"/>
</key-store-ssl-certificate>
</ssl-context>
</ssl-contexts>
<ssl-context-rules>
<rule use-ssl-context="client-ssl-context"/>
</ssl-context-rules>
</authentication-client>
</configuration>
{noformat}
Without installing the Elytron provider, the client will fail with this error:
{noformat}
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:49)
at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:282)
at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:81)
at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:89)
at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:87)
at org.jboss.ejb.client.EJBClientInvocationContext.<init>(EJBClientInvocationContext.java:87)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:154)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
at com.sun.proxy.$Proxy2.hello(Unknown Source)
at client.Client.main(Client.java:21)
Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
at java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
... 10 more
Caused by: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1410)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$28(ElytronXmlParser.java:952)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$36(ElytronXmlParser.java:997)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$21(ElytronXmlParser.java:733)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$25(ElytronXmlParser.java:781)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$10(ElytronXmlParser.java:613)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$11(ElytronXmlParser.java:639)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:337)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:214)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:175)
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
... 12 more
Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear"
at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121)
at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:75)
at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1376)
... 24 more
{noformat}
.. but for example, this snippet DOES NOT require manually adding the provider even though it is using cleartext passwords (which looks like it's related to the aforementioned error):
{noformat}
<authentication-client xmlns="urn:elytron:1.0">
<authentication-rules>
<rule use-configuration="default"/>
</authentication-rules>
<authentication-configurations>
<configuration name="default">
<sasl-mechanism-selector selector="DIGEST-MD5"/>
<set-user-name name="joe"/>
<credentials>
<clear-password password="joeIsAwesome2013!"/>
</credentials>
</configuration>
</authentication-configurations>
</authentication-client>
{noformat}
> Elytron provider has to be installed manually in some client scenarios
> ----------------------------------------------------------------------
>
> Key: ELY-1428
> URL: https://issues.jboss.org/browse/ELY-1428
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Trying to configure ejb client 2-way TLS authentication with Elytron. I can't configure client private key without use of programatically registering Elytron provider.
> {noformat}
> Security.addProvider(new WildFlyElytronProvider());
> {noformat}
> Specifying this in {{wildfly-config.xml}} doesn't help:
> {noformat}
> <providers>
> <use-service-loader/>
> </providers>
> {noformat}
> Example of {{wildfly-config.xml}} where I need this when using it with EJB client:
> {code:xml}
> <configuration>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-rules>
> <rule use-configuration="default"/>
> </authentication-rules>
> <authentication-configurations>
> <configuration name="default">
> <credentials>
> <key-store-reference key-store-name="client-keystore" alias="joe">
> <key-store-clear-password password="abcdef"/>
> </key-store-reference>
> </credentials>
> </configuration>
> </authentication-configurations>
> <key-stores>
> <key-store name="client-keystore" type="JKS">
> <file name="${keystore.path:src/main/resources/client.keystore}"/>
> <key-store-clear-password password="abcdef"/>
> </key-store>
> <key-store name="client-truststore" type="JKS">
> <file name="${truststore.path:src/main/resources/client.truststore}"/>
> </key-store>
> </key-stores>
> <ssl-contexts>
> <ssl-context name="client-ssl-context">
> <trust-store key-store-name="client-truststore"/>
> <key-store-ssl-certificate key-store-name="client-keystore" alias="joe">
> <key-store-clear-password password="abcdef"/>
> </key-store-ssl-certificate>
> </ssl-context>
> </ssl-contexts>
> <ssl-context-rules>
> <rule use-ssl-context="client-ssl-context"/>
> </ssl-context-rules>
> </authentication-client>
> </configuration>
> {code}
> Without installing the Elytron provider, the client will fail with this error:
> {noformat}
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:49)
> at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:282)
> at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:81)
> at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:89)
> at org.wildfly.naming.client.ProviderEnvironment$1.get(ProviderEnvironment.java:87)
> at org.jboss.ejb.client.EJBClientInvocationContext.<init>(EJBClientInvocationContext.java:87)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:154)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> at com.sun.proxy.$Proxy2.hello(Unknown Source)
> at client.Client.main(Client.java:21)
> Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
> at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
> ... 10 more
> Caused by: org.wildfly.client.config.ConfigXMLParseException: ELY01135: Failed to load keystore data
> at file:/home/jmartisk/Workspace/mock-artifacts/ejbclient/eap7.1-elytron-certificate-auth-with-two-way-ssl/client/target/classes/META-INF/wildfly-config.xml:9:87
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1410)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$28(ElytronXmlParser.java:952)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseCredentialsType$36(ElytronXmlParser.java:997)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$21(ElytronXmlParser.java:733)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$26(ElytronXmlParser.java:939)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$25(ElytronXmlParser.java:781)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$10(ElytronXmlParser.java:613)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$11(ElytronXmlParser.java:639)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:337)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:214)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:175)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
> ... 12 more
> Caused by: java.security.NoSuchAlgorithmException: ELY08028: Invalid algorithm "clear"
> at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121)
> at org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:75)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1376)
> ... 24 more
> {noformat}
> Using credential-store-reference clear-text cause similar error.
> There is example of clear passwords which works, so it will be problem of this specific elements:
> {code:xml}
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-rules>
> <rule use-configuration="default"/>
> </authentication-rules>
> <authentication-configurations>
> <configuration name="default">
> <sasl-mechanism-selector selector="DIGEST-MD5"/>
> <set-user-name name="joe"/>
> <credentials>
> <clear-password password="joeIsAwesome2013!"/>
> </credentials>
> </configuration>
> </authentication-configurations>
> </authentication-client>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFLY-9494) Remove jboss-ejb-client.properties and wildfly-config.xml from default locations in the test suite
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-9494?page=com.atlassian.jira.plugin.... ]
Yeray Borges moved JBEAP-13649 to WFLY-9494:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9494 (was: JBEAP-13649)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
Test Suite
(was: EJB)
(was: Test Suite)
> Remove jboss-ejb-client.properties and wildfly-config.xml from default locations in the test suite
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-9494
> URL: https://issues.jboss.org/browse/WFLY-9494
> Project: WildFly
> Issue Type: Task
> Components: EJB, Test Suite
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Critical
>
> Currently, the test suite contains
> {noformat}
> testsuite/integration/basic/src/test/resources/jboss-ejb-client.properties
> testsuite/integration/basic/src/test/resources/wildfly-config.xml
> testsuite/integration/legacy-ejb-client/src/test/resources/jboss-ejb-client.properties
> testsuite/integration/manualmode/src/test/resources/jboss-ejb-client.properties
> {noformat}
> This means that all {{@RunAsClient}} tests pick them up by default and it's very difficult to add new tests which need to use the same configuration files but with different contents than the default ones, without negatively affecting other tests.
> For example, it's not easily possible to make a test completely ignore the {{jboss-ejb-client.properties}} because setting the {{jboss.ejb.client.properties.file.path}} property to an empty string still makes the EJB client use the file from the default location (it is possible to switch to a different valid {{jboss-ejb-client.properties}} but not to just tell the test to not use any at all).
> No such file should be present in the location from which it is picked up by default, tests which need such file should set up paths to them (for example, using {{wildfly.config.url}} and {{jboss.ejb.client.properties.file.path}} system properties).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (SECURITY-982) Some XACML tests fail with security manager
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/SECURITY-982?page=com.atlassian.jira.plug... ]
Yeray Borges resolved SECURITY-982.
-----------------------------------
Fix Version/s: PicketBox_XACML_2.0.10.Final
Resolution: Done
> Some XACML tests fail with security manager
> -------------------------------------------
>
> Key: SECURITY-982
> URL: https://issues.jboss.org/browse/SECURITY-982
> Project: PicketBox
> Issue Type: Bug
> Components: JBossXACML
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Critical
> Labels: security-manager
> Fix For: PicketBox_XACML_2.0.10.Final
>
>
> Some XACML tests fail with security manager, mostly because of missing permission "("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-11.0.0.Final-SNAPSHOT/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.jbossorg-1.jar" "read")":
> {noformat}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /custom-xacml-web-test/secured: java.lang.ExceptionInInitializerError
> at org.jboss.as.test.integration.security.xacml.CustomXACMLAuthorizationModule.<init>(CustomXACMLAuthorizationModule.java:68)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext.instantiateModule(JBossAuthorizationContext.java:329)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext.initializeModules(JBossAuthorizationContext.java:205)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext.authorize(JBossAuthorizationContext.java:141)
> at org.jboss.security.plugins.JBossAuthorizationManager.internalAuthorization(JBossAuthorizationManager.java:438)
> at org.jboss.security.plugins.JBossAuthorizationManager.authorize(JBossAuthorizationManager.java:115)
> at org.jboss.security.plugins.javaee.WebAuthorizationHelper.checkResourcePermission(WebAuthorizationHelper.java:119)
> at org.wildfly.extension.undertow.security.JbossAuthorizationManager.canAccessResource(JbossAuthorizationManager.java:160)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:55)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-11.0.0.Final-SNAPSHOT/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.jbossorg-1.jar" "read")" in code source "(vfs:/content/custom-xacml-web-test.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.custom-xacml-web-test.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.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350)
> at java.util.zip.ZipFile.<init>(ZipFile.java:216)
> at java.util.zip.ZipFile.<init>(ZipFile.java:155)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:84)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1045)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:292)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)
> at org.jboss.security.xacml.core.JBossPDP.<clinit>(JBossPDP.java:126)
> ... 55 more
> {noformat}
> Looks like a privileged block is missing. Hence Critical.
> After adding such permission, there are another permissions missing:
> * {{WebXACMLAuthorizationModuleTestCase}} -- {{RuntimePermission("accessDeclaredMembers")}}, {{ReflectPermission("suppressAccessChecks")}}, {{RuntimePermission("getClassLoader")}}
> * {{JBossPDPServletInitializationTestCase}} -- {{RuntimePermission("accessDeclaredMembers")}}
> * {{JBossPDPInteroperabilityTestCase}} -- additional file permissions, {{RuntimePermission("accessDeclaredMembers")}}, {{RuntimePermission("getClassLoader")}}, {{ReflectPermission("suppressAccessChecks")}}, {{PropertyPermission("user.dir", "read")}}
> * {{EjbXACMLAuthorizationModuleTestCase}} -- {{RuntimePermission("accessDeclaredMembers")}}, {{RuntimePermission("getClassLoader")}}, {{ReflectPermission("suppressAccessChecks")}}, {{ElytronPermission("getSecurityDomain")}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFLY-9493) Wildfly 11 SerialVersionUID does not match
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/WFLY-9493?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš deleted WFLY-9493:
----------------------------------
> Wildfly 11 SerialVersionUID does not match
> ------------------------------------------
>
> Key: WFLY-9493
> URL: https://issues.jboss.org/browse/WFLY-9493
> Project: WildFly
> Issue Type: Feature Request
> Reporter: leonardo truccollo
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: support
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> I'm using wildfly 10.1.0.final in our software with no problems, when migrating to the latest version of wildfly 11 the same project started to appear the error of SerialVersionUID does not match, being that if I turn off the wildfly 11 and re-use the 10 same does not bring any error only in wildfly 11,
> the two Servers contain exactly the same compiled build.
> This happens every time I update a field in the client, that it goes until the sources make a request.
> Something has changed in 11 so that it does not find this parameter, all fonts contain SerialVersionUID = 1L
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFLY-9480) Undertow Web-Socket when using Atmosphere
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9480?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-9480:
--------------------------------------
Looks like we are not handling the contract for ServletRequest.setAttribute correctly, and calling set with a null value will not clear the key but will instead just associate it with a null value. Atmosphere then attempts to put this into a concurrent map which then blows up. I will fix Undertow so this method will work correctly.
> Undertow Web-Socket when using Atmosphere
> -----------------------------------------
>
> Key: WFLY-9480
> URL: https://issues.jboss.org/browse/WFLY-9480
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Final
> Environment: CentOS in Docker.
> Reporter: Jason Bruwer
> Assignee: Stuart Douglas
>
> 2017-10-25 13:26:54,166 DEBUG [com.flowjob.web.backing.ABaseManagedBean] (default task-25) * User Populate Top Menu Model Took '1' millis.
> 2017-10-25 13:26:54,166 DEBUG [com.flowjob.web.backing.ABaseManagedBean] (default task-25) User Retrieve All Personal Inventory Items Took '0' millis.
> 2017-10-25 13:26:54,718 DEBUG [com.flowjob.web.backing.push.endpoint.RefreshViewEndpoint] (Atmosphere-Scheduler-190) [/refresh_view] : onClose()
> 2017-10-25 13:26:54,744 DEBUG [com.flowjob.web.backing.push.endpoint.RefreshViewEndpoint] (default task-28) [/refresh_view] : onOpen()
> 2017-10-25 13:26:55,022 ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /fluid/primepush/user_session/ZKAen-M9wRcAFnnjsaI2wzjb0sBE80YCWPRChM-j: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
> at org.atmosphere.cpr.AtmosphereRequest$LocalAttributes.put(AtmosphereRequest.java:589)
> at org.atmosphere.cpr.AtmosphereRequestImpl.wrap(AtmosphereRequestImpl.java:1415)
> at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:191)
> at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:177)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:130)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2017-10-25 13:26:55,228 ERROR [org.jboss.weld.Bean] (default task-25) WELD-000019: Error destroying an instance com.flowjob.web.backing.attachment.AttachmentBean@355e10bd of Managed Bean [class com.flowjob.web.backing.attachment.AttachmentBean] with qualifiers [@Default @Named @Any]
> 2017-10-25 13:26:55,242 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /fluid/primepush/refresh_view: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFCORE-1307) jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1307?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1307:
-------------------------------------
Fix Version/s: 4.0.0.Alpha3
(was: 4.0.0.Alpha2)
> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1307
> URL: https://issues.jboss.org/browse/WFCORE-1307
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Assignee: Ken Wills
> Fix For: 4.0.0.Alpha3
>
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed.
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone@localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at java.nio.file.Files.copy(Files.java:3004)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1145:
-------------------------------------
Fix Version/s: 4.0.0.Alpha3
(was: 4.0.0.Alpha2)
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron, domain-mode
> Fix For: 4.0.0.Alpha3
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months
[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-887:
------------------------------------
Fix Version/s: 4.0.0.Alpha3
(was: 4.0.0.Alpha2)
> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
> Key: WFCORE-887
> URL: https://issues.jboss.org/browse/WFCORE-887
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Alpha3
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We should look for other cases like this too, although those changes should be separate JIRAs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 6 months