[JBoss JIRA] (ELY-1292) XmlConfigurationTest.testCertificateInCredentials hangs on IBM JDK
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/ELY-1292?page=com.atlassian.jira.plugin.s... ]
Peter Palaga updated ELY-1292:
------------------------------
Steps to Reproduce:
{code}
export JAVA_HOME=path/to/ibm/java8
$JAVA_HOME/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160915_0912_B318796
JIT - tr.r14.java.green_20160818_122998
GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
J9CL - 20160915_318796)
JCL - 20160914_01 based on Oracle jdk8u101-b13
mvn clean test -Dtest=XmlConfigurationTest
{code}
Expected: XmlConfigurationTest teminates after a reasonable amount of time
Actual: XmlConfigurationTest#testCertificateInCredentials runs forever
was:
{code}
JAVA_HOME=path/to/ibm/java8
$JAVA_HOME/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160915_0912_B318796
JIT - tr.r14.java.green_20160818_122998
GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
J9CL - 20160915_318796)
JCL - 20160914_01 based on Oracle jdk8u101-b13
mvn clean test -Dtest=XmlConfigurationTest
{code}
Expected: XmlConfigurationTest teminates after a reasonable amount of time
Actual: XmlConfigurationTest#testCertificateInCredentials runs forever
> XmlConfigurationTest.testCertificateInCredentials hangs on IBM JDK
> ------------------------------------------------------------------
>
> Key: ELY-1292
> URL: https://issues.jboss.org/browse/ELY-1292
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Peter Palaga
> Assignee: Darran Lofthouse
>
> {{XmlConfigurationTest.testCertificateInCredentials}} does not terminate on IBM JDK.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ]
Peter Palaga updated ELY-1295:
------------------------------
Description:
{code}
export JAVA_HOME=path/to/ibm/java8
$JAVA_HOME/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160915_0912_B318796
JIT - tr.r14.java.green_20160818_122998
GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
J9CL - 20160915_318796)
JCL - 20160914_01 based on Oracle jdk8u101-b13
mvn clean test -Dtest=KeyStoreCredentialStoreTest
{code}
Expected: KeyStoreCredentialStoreTest should pass
Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
{code}
java.lang.ClassNotFoundException: javax.crypto.JceSecurity
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:278)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
...
{code}
because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
{code}
org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:508)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
at java.security.KeyStore.getEntry(KeyStore.java:1532)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
... 10 more
Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
... 12 more
{code}
[1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
was:
{code}
JAVA_HOME=path/to/ibm/java8
$JAVA_HOME/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160915_0912_B318796
JIT - tr.r14.java.green_20160818_122998
GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
J9CL - 20160915_318796)
JCL - 20160914_01 based on Oracle jdk8u101-b13
mvn clean test -Dtest=KeyStoreCredentialStoreTest
{code}
Expected: KeyStoreCredentialStoreTest should pass
Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
{code}
java.lang.ClassNotFoundException: javax.crypto.JceSecurity
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:278)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
...
{code}
because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
{code}
org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:508)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
at java.security.KeyStore.getEntry(KeyStore.java:1532)
at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
... 10 more
Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
... 12 more
{code}
[1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
> Key: ELY-1295
> URL: https://issues.jboss.org/browse/ELY-1295
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Peter Palaga
> Assignee: Darran Lofthouse
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> at java.security.KeyStore.getEntry(KeyStore.java:1532)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> ... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1293) System.currentTimeMillis() cannot be mocked on IBM JDK
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/ELY-1293?page=com.atlassian.jira.plugin.s... ]
Peter Palaga updated ELY-1293:
------------------------------
Description:
{{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
{code}
export JAVA_HOME=path/to/ibm/java8
$JAVA_HOME/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160915_0912_B318796
JIT - tr.r14.java.green_20160818_122998
GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
J9CL - 20160915_318796)
JCL - 20160914_01 based on Oracle jdk8u101-b13
mvn clean test
{code}
Expected: the tests mocking {{System.currentTimeMillis()}} should pass
Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
{code}
java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:508)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{code}
This is the case with
* PeriodicRotatingFileAuditEndpointTest
* SizeRotatingFileAuditEndpointTest
* GssapiCompatibilitySuiteChild
was:
{{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
{code}
JAVA_HOME=path/to/ibm/java8
$JAVA_HOME/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160915_0912_B318796
JIT - tr.r14.java.green_20160818_122998
GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
J9CL - 20160915_318796)
JCL - 20160914_01 based on Oracle jdk8u101-b13
mvn clean test
{code}
Expected: the tests mocking {{System.currentTimeMillis()}} should pass
Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
{code}
java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:508)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{code}
This is the case with
* PeriodicRotatingFileAuditEndpointTest
* SizeRotatingFileAuditEndpointTest
* GssapiCompatibilitySuiteChild
> System.currentTimeMillis() cannot be mocked on IBM JDK
> ------------------------------------------------------
>
> Key: ELY-1293
> URL: https://issues.jboss.org/browse/ELY-1293
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Peter Palaga
> Assignee: Peter Palaga
>
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is the case with
> * PeriodicRotatingFileAuditEndpointTest
> * SizeRotatingFileAuditEndpointTest
> * GssapiCompatibilitySuiteChild
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3084) Permission check failed for RemotingPermission "createEndpoint" even if it is granted
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3084?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-3084:
---------------------------------
Affects Version/s: 3.0.0.Beta28
> Permission check failed for RemotingPermission "createEndpoint" even if it is granted
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-3084
> URL: https://issues.jboss.org/browse/WFCORE-3084
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta28
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> In case when deployment which needs RemotingPermission "createEndpoint" has granted "org.jboss.remoting3.security.RemotingPermission" "createEndpoint" in META-INT/permissions.xml then it still fails with:
> {code}
> java.io.IOException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/direct-call-dep.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.direct-call-dep.war" from Service Module Loader")
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> at com.redhat.eap.qe.elytron.authnctx.DirectCallServlet.doGet(DirectCallServlet.java:84)
> ... 42 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/direct-call-dep.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.direct-call-dep.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 org.jboss.remoting3.EndpointBuilder.build(EndpointBuilder.java:90)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:128)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> ... 44 more
> {code}
> When {{java.security.AllPermission}} is granted to deployment (instead of RemotingPermission "createEndpoint") then it works fine. See 'Steps to Reproduce' for more details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3084) Permission check failed for RemotingPermission "createEndpoint" even if it is granted
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFCORE-3084:
------------------------------------
Summary: Permission check failed for RemotingPermission "createEndpoint" even if it is granted
Key: WFCORE-3084
URL: https://issues.jboss.org/browse/WFCORE-3084
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
In case when deployment which needs RemotingPermission "createEndpoint" has granted "org.jboss.remoting3.security.RemotingPermission" "createEndpoint" in META-INT/permissions.xml then it still fails with:
{code}
java.io.IOException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/direct-call-dep.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.direct-call-dep.war" from Service Module Loader")
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
at com.redhat.eap.qe.elytron.authnctx.DirectCallServlet.doGet(DirectCallServlet.java:84)
... 42 more
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/direct-call-dep.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.direct-call-dep.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 org.jboss.remoting3.EndpointBuilder.build(EndpointBuilder.java:90)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:128)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
... 44 more
{code}
When {{java.security.AllPermission}} is granted to deployment (instead of RemotingPermission "createEndpoint") then it works fine. See 'Steps to Reproduce' for more details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1294) Wildfly Elytron Tool, Credential-store command, --salt option is validated only when --summary is used too.
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/ELY-1294?page=com.atlassian.jira.plugin.s... ]
Chao Wang reassigned ELY-1294:
------------------------------
Assignee: Chao Wang (was: Darran Lofthouse)
> Wildfly Elytron Tool, Credential-store command, --salt option is validated only when --summary is used too.
> -----------------------------------------------------------------------------------------------------------
>
> Key: ELY-1294
> URL: https://issues.jboss.org/browse/ELY-1294
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Chao Wang
>
> Credential-store command \-\-salt option is validated only when is \-\-summary is used too.
> It is caused by generation MASKed password for summary output[1].
> It is at least strange and confusing to user: without \-\-summary is passed, with \-\-summary is failed (entry is stored in storage successfully).
> *How to reproduce*
> {code}
> [hsvabek@dhcp-10-40-5-17 bin]$ ./elytron-tool.sh credential-store --add secret_alias --password pass123 --create -x secret_password -l store005.jceks -s 1234567890 -i 230 --summary --debug
> Alias "secret_alias" has been successfully stored
> Exception encountered executing the command:
> java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long
> at com.sun.crypto.provider.PBES1Core.init(PBES1Core.java:234)
> at com.sun.crypto.provider.PBES1Core.init(PBES1Core.java:331)
> at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineInit(PBEWithMD5AndDESCipher.java:228)
> at javax.crypto.Cipher.implInit(Cipher.java:810)
> at javax.crypto.Cipher.chooseProvider(Cipher.java:864)
> at javax.crypto.Cipher.init(Cipher.java:1539)
> at javax.crypto.Cipher.init(Cipher.java:1470)
> at org.wildfly.security.util.PasswordBasedEncryptionUtil$Builder.createAndInitCipher(PasswordBasedEncryptionUtil.java:506)
> at org.wildfly.security.util.PasswordBasedEncryptionUtil$Builder.build(PasswordBasedEncryptionUtil.java:589)
> at org.wildfly.security.tool.MaskCommand.computeMasked(MaskCommand.java:117)
> at org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:287)
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.CR2/s...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3083) Capability reload-required tracking breaks down if the cap is reload-required because of removal
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3083:
----------------------------------------
Summary: Capability reload-required tracking breaks down if the cap is reload-required because of removal
Key: WFCORE-3083
URL: https://issues.jboss.org/browse/WFCORE-3083
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Critical
The WFCORE-1106 fix has a big flaw in how it tracks what capabilities are affected when a resource reports reload-required or restart-required. It only examines currently registered caps, but in the resource removal case the op that is calling reloadRequired() will have removed the cap in an earlier stage. So the fact the cap should be reload-required is not recorded.
The WFCORE-1106 integration test doesn't capture this because it uses write-attribute ops to trigger reload-required.
I discovered this when manually verifying the WFLY-4970 scenario was fixed. Turns out it wasn't.
I think the simple solution is to have the CapabilityRegistry cache the removed capabilities and also use that cache when checking what caps are affected by reload/restart required. The cache can be cleared on each publish or rollback of the registry because the data does not need to be retained beyond the span of the op that is making the changes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2793) Consolidate scheduled thread pool usage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2793?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2793:
------------------------------------------
https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... has work on this, but additional unit testing of the executor is needed and I haven't had time.
> Consolidate scheduled thread pool usage
> ---------------------------------------
>
> Key: WFCORE-2793
> URL: https://issues.jboss.org/browse/WFCORE-2793
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Look into whether we can consolidate thread usage for scheduled tasks.
> 1) Get rid of the "DeploymentScanner Threads" pool
> The deployment scanner can use the kernel scheduled executor. I'm a bit reluctant in general to allow use of this pool by subsystems as scheduled executors have a fixed size pool, so arbitrary usage by subsystems can result in tying up all the threads doing long running tasks and undesirable behavior. But deployment-scanner is "kernel-ish enough" that I think it's ok.
> This will remove 2 threads.
> The server scheduled executor has 4 threads which is actually pretty high given the very limited usage of it. So I'll consider narrowing it down.
> The big problem with using the server scheduled executor is tying up its threads long running tasks, which the scanner does do. What i'll probably do is just use the scheduled executor to trigger a task which then submits a task on the main ServerService thread pool (which is unlimited in size.)
> Perhaps I'll abstract this kind of usage pattern into a service, and make that service a generally available kernel capability.
> 2) Get rid of the "ServerDeploymentRepository-temp-threads" pool
> This one is used by DeploymentMountProvider to do file cleanup. Similar discussion applies.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9117) Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9117:
--------------------------------------
Summary: Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements
Key: WFLY-9117
URL: https://issues.jboss.org/browse/WFLY-9117
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
RuntimeCapability.Builder add[Dynamic|Optional|RuntimeOnly]Requirements are deprecated because at the moment they have no practical function. The idea for them was to hold some metadata about a capability for description presentation in a ui or some kind of use by a provisioning tool. But that is a use case that hasn't been pursued yet.
What they don't do is somehow automatically wire up requirements when the capability is registered, the way requirements added via RuntimeCapability.Builder.addRequirements are wired. That's because for a dynamic cap the dynamic part of the required cap's name is not known to the kernel, and for an optional requirement whether whatever condition makes the requirement non-optional has been met is unknown to the kernel.
But it looks like there's some use of these methods where the code assumes some autowiring will happen. The problem reported in WFCORE-3040 is an example of this.
Reproducer, starting with a near empty config a la standalone-minimalistic.xml:
{code:java}
/extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow")
/extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io")
batch
/subsystem=undertow:add
/subsystem=undertow/servlet-container=default:add
/subsystem=undertow/server=default-server:add
/subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"])
/subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http")
/subsystem=undertow/buffer-cache=default:add
/subsystem=undertow/configuration=handler:add
/subsystem=undertow/configuration=filter:add
/subsystem=io:add
/subsystem=io/buffer-pool=default:add
/subsystem=io/worker=default:add
/socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}")
run-batch
{code}
The server service is not added because the op is executed post-boot, so it's capability is tracked as requiring reload. But when adding the listener, the requirement for the server is not being added (because of this bug). So, without the requirement data to tell it things are not ready (see WFCORE-1106 for details) the kernel is not detecting the reload-required dependency and is trying to execute the stage RUNTIME steps for the listener add. These fail due to the missing dependency.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9116) Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9116?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9116:
-----------------------------------
Description:
RuntimeCapability.Builder add[Dynamic|Optional|RuntimeOnly]Requirements are deprecated because at the moment they have no practical function. The idea for them was to hold some metadata about a capability for description presentation in a ui or some kind of use by a provisioning tool. But that is a use case that hasn't been pursued yet.
What they don't do is somehow automatically wire up requirements when the capability is registered, the way requirements added via RuntimeCapability.Builder.addRequirements are wired. That's because for a dynamic cap the dynamic part of the required cap's name is not known to the kernel, and for an optional requirement whether whatever condition makes the requirement non-optional has been met is unknown to the kernel.
But it looks like there's some use of these methods where the code assumes some autowiring will happen. The problem reported in WFCORE-3040 is an example of this.
Reproducer, starting with a near empty config a la standalone-minimalistic.xml:
{code:java}
/extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow")
/extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io")
batch
/subsystem=undertow:add
/subsystem=undertow/servlet-container=default:add
/subsystem=undertow/server=default-server:add
/subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"])
/subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http")
/subsystem=undertow/buffer-cache=default:add
/subsystem=undertow/configuration=handler:add
/subsystem=undertow/configuration=filter:add
/subsystem=io:add
/subsystem=io/buffer-pool=default:add
/subsystem=io/worker=default:add
/socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}")
run-batch
{code}
The server service is not added because the op is executed post-boot, so it's capability is tracked as requiring reload. But when adding the listener, the requirement for the server is not being added (because of this bug). So, without the requirement data to tell it things are not ready (see WFCORE-1106 for details) the kernel is not detecting the reload-required dependency and is trying to execute the stage RUNTIME steps for the listener add. These fail due to the missing dependency.
was:
RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements are deprecated because at the moment they have no practical function. The idea for them was to hold some metadata about a capability for description presentation in a ui or some kind of use by a provisioning tool. But that is a use case that hasn't been pursued.
What they don't do is somehow automatically wire up requirements when the capability is registered, the way requirements added via RuntimeCapability.Builder.addRequirements are wired. That's because for a dynamic cap the dynamic part of the required cap's name is not known to the kernel, and for an optional requirement whether whatever condition makes the requirement non-optional has been met is unknown to the kernel.
But it looks like there's some use of these methods where the code assumes some autowiring will happen. The problem reported in WFCORE-3040 is an example of this.
Reproducer, starting with a near empty config a la standalone-minimalistic.xml:
{code:java}
/extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow")
/extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io")
batch
/subsystem=undertow:add
/subsystem=undertow/servlet-container=default:add
/subsystem=undertow/server=default-server:add
/subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"])
/subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http")
/subsystem=undertow/buffer-cache=default:add
/subsystem=undertow/configuration=handler:add
/subsystem=undertow/configuration=filter:add
/subsystem=io:add
/subsystem=io/buffer-pool=default:add
/subsystem=io/worker=default:add
/socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}")
run-batch
{code}
The server service is not added because the op is executed post-boot, so it's capability is tracked as requiring reload. But when adding the listener, the requirement for the server is not being added (because of this bug). So, without the requirement data to tell it things are not ready (see WFCORE-1106 for details) the kernel is not detecting the reload-required dependency and is trying to execute the stage RUNTIME steps for the listener add. These fail due to the missing dependency.
> Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9116
> URL: https://issues.jboss.org/browse/WFLY-9116
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> RuntimeCapability.Builder add[Dynamic|Optional|RuntimeOnly]Requirements are deprecated because at the moment they have no practical function. The idea for them was to hold some metadata about a capability for description presentation in a ui or some kind of use by a provisioning tool. But that is a use case that hasn't been pursued yet.
> What they don't do is somehow automatically wire up requirements when the capability is registered, the way requirements added via RuntimeCapability.Builder.addRequirements are wired. That's because for a dynamic cap the dynamic part of the required cap's name is not known to the kernel, and for an optional requirement whether whatever condition makes the requirement non-optional has been met is unknown to the kernel.
> But it looks like there's some use of these methods where the code assumes some autowiring will happen. The problem reported in WFCORE-3040 is an example of this.
> Reproducer, starting with a near empty config a la standalone-minimalistic.xml:
> {code:java}
> /extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow")
> /extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io")
> batch
> /subsystem=undertow:add
> /subsystem=undertow/servlet-container=default:add
> /subsystem=undertow/server=default-server:add
> /subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"])
> /subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http")
> /subsystem=undertow/buffer-cache=default:add
> /subsystem=undertow/configuration=handler:add
> /subsystem=undertow/configuration=filter:add
> /subsystem=io:add
> /subsystem=io/buffer-pool=default:add
> /subsystem=io/worker=default:add
> /socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}")
> run-batch
> {code}
> The server service is not added because the op is executed post-boot, so it's capability is tracked as requiring reload. But when adding the listener, the requirement for the server is not being added (because of this bug). So, without the requirement data to tell it things are not ready (see WFCORE-1106 for details) the kernel is not detecting the reload-required dependency and is trying to execute the stage RUNTIME steps for the listener add. These fail due to the missing dependency.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months