[JBoss JIRA] (DROOLS-1004) classloading errors in kie-server
by Karel Suta (Jira)
[ https://issues.redhat.com/browse/DROOLS-1004?page=com.atlassian.jira.plug... ]
Karel Suta commented on DROOLS-1004:
------------------------------------
Jaxb warnings are still present in Kie server logs.
I haven't seen the OSGI issue.
> classloading errors in kie-server
> ---------------------------------
>
> Key: DROOLS-1004
> URL: https://issues.redhat.com/browse/DROOLS-1004
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: David Ward
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> There appear to be some classloading errors in kie-server.war 6.3.0.Final-redhat-5 being deployed on JBoss EAP 6.4.4.
> *First, you get multiple jaxb and parser warnings like this:*
> {code}
> 11:58:47,603 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-api.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-core-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,606 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-impl-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-impl.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,713 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.xmlpull.mxp1.MXParser,org.xmlpull.mxp1_serializer.MXSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'
> {code}
> The above was noticed as part of CLOUD-421. Please refer to the jira issue and note Kev's comment, {quote}"The jaxb jars are duplicates that are unnecessary in the EAP deployments however the upstream war file contains all dependencies. Removing the jaxb jars from within the kie-server.war/WEB-INF/lib directory will likely work however I'm loathed to do this since we would need to verify this through the BRMS QE team.
> The warning about the parser is caused by the kie-server.war/WEB-INF/lib/xpp3_min-1.1.4c.jar"{quote}
> *Second, there can be missing osgi classes:*
> If kjar model classes contain certain annotations, it seems to trigger the kie-server to try to load osgi classes. For example, annotating kjar model classes with Position, PropertyReactive, and Remotable as per this test case:
> http://git.app.eng.bos.redhat.com/git/xpaas-qe.git/tree/test-brms/src/tes...
> , you end up with errors like this in the log when the KieContainer is being installed:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTrackerCustomizer
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_65]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760) [rt.jar:1.8.0_65]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
> ... 77 more
> Caused by: java.lang.ClassNotFoundException: org.osgi.util.tracker.ServiceTrackerCustomizer from [Module "deployment.kie-server.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
> ... 81 more
> {code}
> The above was noticed as part of CLOUD-418. To get around this issue, I had to add a kie-server.war/WEB-INF/jboss-deployment-structure.xml like so:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <module name="org.osgi.core"/>
> <module name="org.osgi.enterprise"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> The jboss-bpmsuite-6.2.0.GA-redhat-1-deployable-eap6.x.zip file (from which we extract the kie-sever.war) is seemingly an EAP-specific build (thus the -eap6.x suffix). So perhaps the fix would be to have the kie-server.war already come pre-configured to contain (or better yet, depend upon the existing modules) jars in EAP for both the above problems (incorrect jaxb/xmlpull references, and missing osgi dependencies).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-1003) incongruous security granularity in kie-server
by David Ward (Jira)
[ https://issues.redhat.com/browse/DROOLS-1003?page=com.atlassian.jira.plug... ]
David Ward updated DROOLS-1003:
-------------------------------
Priority: Minor (was: Major)
> incongruous security granularity in kie-server
> ----------------------------------------------
>
> Key: DROOLS-1003
> URL: https://issues.redhat.com/browse/DROOLS-1003
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: David Ward
> Assignee: Toshiya Kobayashi
> Priority: Minor
> Attachments: web.xml
>
>
> The KIE Server provides two endpoints: HTTP/REST and JMS. By default, there is a "kie-server" role that one must have to perform operations through either endpoint. But by having this role, you can do *anything* in a very coarse-grained fashion.
> Luckily, the HTTP/REST endpoint can be modified by changing the kie-server.war/WEB-INF/web.xml, and adding/modifying the security constraints. For OpenShift purposes, this has been done to disallow creating and disposing containers, while still allowing for reading status and executing rules. This is because REST url-patterns can be filtered per various operations and also with different http-methods. (See attached web.xml for an example.)
> However, the JMS endpoint has no such capability. There is only one request queue with appserver security on it on a coarse-grained level, and no way to filter the messages as can be done via the HTTP/REST endpoint.
> I have an idea that might help? Clients invoke the server via serializing and sending in Command objects, and those objects themselves are fine-grained (they are named things like "CallContainerCommand" and "DisposeContainerCommand"). If the incoming messages could propagate some kind of property of who the caller was, then the server-side could do a isCallerInRole/isUserInRole to determine if that user is authorized to invoke that particular command before doing so. Just a brainstorming idea.
> Here is an example of the server handling the commands:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.2.x/kie-serve...
> The desired goal would be that developers (like myself) would not have to edit the kie-server.war/WEB-INF/web.xml, and that the same level of security granularity would already be available out-of-the-box for both the HTTP/REST and JMS interfaces. All that would be left for us would be to grant users the appropriate roles.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-1003) incongruous security granularity in kie-server
by David Ward (Jira)
[ https://issues.redhat.com/browse/DROOLS-1003?page=com.atlassian.jira.plug... ]
David Ward commented on DROOLS-1003:
------------------------------------
Hi [~tkobayashi], I think this issue is low priority now, and I will update this Jira accordingly. Most people who use the kieserver do so using REST, not JMS. And if they are using JMS, it is almost always internal to a cluster and not exposed externally anyways. Last, I believe security roles have changed between 6 and 7, so this might not even be an issue anymore, but further investigation would have to be done to make sure.
> incongruous security granularity in kie-server
> ----------------------------------------------
>
> Key: DROOLS-1003
> URL: https://issues.redhat.com/browse/DROOLS-1003
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: David Ward
> Assignee: Toshiya Kobayashi
> Priority: Major
> Attachments: web.xml
>
>
> The KIE Server provides two endpoints: HTTP/REST and JMS. By default, there is a "kie-server" role that one must have to perform operations through either endpoint. But by having this role, you can do *anything* in a very coarse-grained fashion.
> Luckily, the HTTP/REST endpoint can be modified by changing the kie-server.war/WEB-INF/web.xml, and adding/modifying the security constraints. For OpenShift purposes, this has been done to disallow creating and disposing containers, while still allowing for reading status and executing rules. This is because REST url-patterns can be filtered per various operations and also with different http-methods. (See attached web.xml for an example.)
> However, the JMS endpoint has no such capability. There is only one request queue with appserver security on it on a coarse-grained level, and no way to filter the messages as can be done via the HTTP/REST endpoint.
> I have an idea that might help? Clients invoke the server via serializing and sending in Command objects, and those objects themselves are fine-grained (they are named things like "CallContainerCommand" and "DisposeContainerCommand"). If the incoming messages could propagate some kind of property of who the caller was, then the server-side could do a isCallerInRole/isUserInRole to determine if that user is authorized to invoke that particular command before doing so. Just a brainstorming idea.
> Here is an example of the server handling the commands:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.2.x/kie-serve...
> The desired goal would be that developers (like myself) would not have to edit the kie-server.war/WEB-INF/web.xml, and that the same level of security granularity would already be available out-of-the-box for both the HTTP/REST and JMS interfaces. All that would be left for us would be to grant users the appropriate roles.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-1004) classloading errors in kie-server
by David Ward (Jira)
[ https://issues.redhat.com/browse/DROOLS-1004?page=com.atlassian.jira.plug... ]
David Ward commented on DROOLS-1004:
------------------------------------
[~tkobayashi], this is most likely out-of-date. I don't recall seeing these errors in quite some time. In fact, I don't remember seeing them at all in the 7 series. [~filippe.spolti], [~jschwan], [~ksuta], can you please confirm?
> classloading errors in kie-server
> ---------------------------------
>
> Key: DROOLS-1004
> URL: https://issues.redhat.com/browse/DROOLS-1004
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: David Ward
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> There appear to be some classloading errors in kie-server.war 6.3.0.Final-redhat-5 being deployed on JBoss EAP 6.4.4.
> *First, you get multiple jaxb and parser warnings like this:*
> {code}
> 11:58:47,603 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-api.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-core-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,606 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-impl-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-impl.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,713 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.xmlpull.mxp1.MXParser,org.xmlpull.mxp1_serializer.MXSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'
> {code}
> The above was noticed as part of CLOUD-421. Please refer to the jira issue and note Kev's comment, {quote}"The jaxb jars are duplicates that are unnecessary in the EAP deployments however the upstream war file contains all dependencies. Removing the jaxb jars from within the kie-server.war/WEB-INF/lib directory will likely work however I'm loathed to do this since we would need to verify this through the BRMS QE team.
> The warning about the parser is caused by the kie-server.war/WEB-INF/lib/xpp3_min-1.1.4c.jar"{quote}
> *Second, there can be missing osgi classes:*
> If kjar model classes contain certain annotations, it seems to trigger the kie-server to try to load osgi classes. For example, annotating kjar model classes with Position, PropertyReactive, and Remotable as per this test case:
> http://git.app.eng.bos.redhat.com/git/xpaas-qe.git/tree/test-brms/src/tes...
> , you end up with errors like this in the log when the KieContainer is being installed:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTrackerCustomizer
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_65]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760) [rt.jar:1.8.0_65]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
> ... 77 more
> Caused by: java.lang.ClassNotFoundException: org.osgi.util.tracker.ServiceTrackerCustomizer from [Module "deployment.kie-server.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
> ... 81 more
> {code}
> The above was noticed as part of CLOUD-418. To get around this issue, I had to add a kie-server.war/WEB-INF/jboss-deployment-structure.xml like so:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <module name="org.osgi.core"/>
> <module name="org.osgi.enterprise"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> The jboss-bpmsuite-6.2.0.GA-redhat-1-deployable-eap6.x.zip file (from which we extract the kie-sever.war) is seemingly an EAP-specific build (thus the -eap6.x suffix). So perhaps the fix would be to have the kie-server.war already come pre-configured to contain (or better yet, depend upon the existing modules) jars in EAP for both the above problems (incorrect jaxb/xmlpull references, and missing osgi dependencies).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5047) libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5047?page=com.atlassian.jira.plug... ]
Farah Juma updated WFCORE-5047:
-------------------------------
Priority: Major (was: Blocker)
> libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-5047
> URL: https://issues.redhat.com/browse/WFCORE-5047
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
>
> Looks like detection of `libwfssl` is broken in current build. When I try to configure OpenSSL security provider in legacy security, I can see following errors in standalone.log:
> {code:java}
> 15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748)Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) at java.security.Provider$Service.newInstance(Provider.java:1617) at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at sun.security.jca.GetInstance.getInstance(GetInstance.java:164) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105) ... 8 moreCaused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.wildfly.openssl.SSL.init(SSL.java:87) at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129) at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi.<init>(OpenSSLContextSPI.java:484) 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.security.Provider$Service.newInstance(Provider.java:1595) ... 12 moreCaused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.wildfly.openssl.SSL.init(SSL.java:82) ... 19 moreCaused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1124) at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288) ... 24 more
> 15:39:44,818 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("core-service" => "management"), ("security-realm" => "ApplicationRealm")]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context" => "WFLYDM0018: Unable to start service Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException Caused by: java.lang.reflect.InvocationTargetException Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path"}} {code}
>
> This is a regression against previous release - {{EAP7.3.1}}. Expected behaviour is no error in the log, libwfssl is loaded successfully and OpenSSL is correctly used for TLS connections.
> Note - there has been a change in the location of the particular libwfssl native binaries in the distribution, see https://github.com/wildfly-security/wildfly-openssl/commit/c5c07d3dc0d637...
> {code:title=7.3.1}
> $ find . -name *wfssl*
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-i386/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so
> {code}
> and
> {code:title=7.4.0.CD20-CR1}
> $ find . -name *ssl*
> ./modules/system/layers/base/org/wildfly/openssl
> ./modules/system/layers/base/org/wildfly/openssl/main/wildfly-openssl-java-1.1.0.Final-redhat-00001.jar
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/el8-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/el7-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-i386/libwfssl.so
> ./modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-ssl-1.12.1.Final-redhat-00001.jar
> {code}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5047) libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5047?page=com.atlassian.jira.plug... ]
Farah Juma moved JBEAP-19905 to WFCORE-5047:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-5047 (was: JBEAP-19905)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
(was: Web (Undertow))
Affects Version/s: (was: 7.4.0.CD20-CR1)
> libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-5047
> URL: https://issues.redhat.com/browse/WFCORE-5047
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Blocker
>
> Looks like detection of `libwfssl` is broken in current build. When I try to configure OpenSSL security provider in legacy security, I can see following errors in standalone.log:
> {code:java}
> 15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748)Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) at java.security.Provider$Service.newInstance(Provider.java:1617) at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at sun.security.jca.GetInstance.getInstance(GetInstance.java:164) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105) ... 8 moreCaused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.wildfly.openssl.SSL.init(SSL.java:87) at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129) at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi.<init>(OpenSSLContextSPI.java:484) 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.security.Provider$Service.newInstance(Provider.java:1595) ... 12 moreCaused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.wildfly.openssl.SSL.init(SSL.java:82) ... 19 moreCaused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1124) at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288) ... 24 more
> 15:39:44,818 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("core-service" => "management"), ("security-realm" => "ApplicationRealm")]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context" => "WFLYDM0018: Unable to start service Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException Caused by: java.lang.reflect.InvocationTargetException Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path"}} {code}
>
> This is a regression against previous release - {{EAP7.3.1}}. Expected behaviour is no error in the log, libwfssl is loaded successfully and OpenSSL is correctly used for TLS connections.
> Note - there has been a change in the location of the particular libwfssl native binaries in the distribution, see https://github.com/wildfly-security/wildfly-openssl/commit/c5c07d3dc0d637...
> {code:title=7.3.1}
> $ find . -name *wfssl*
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-i386/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so
> {code}
> and
> {code:title=7.4.0.CD20-CR1}
> $ find . -name *ssl*
> ./modules/system/layers/base/org/wildfly/openssl
> ./modules/system/layers/base/org/wildfly/openssl/main/wildfly-openssl-java-1.1.0.Final-redhat-00001.jar
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/el8-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/el7-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-x86_64/libwfssl.so
> ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-i386/libwfssl.so
> ./modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-ssl-1.12.1.Final-redhat-00001.jar
> {code}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months