March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4805) WildFly Security Manager does not act for javaagents

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFCORE-4805?page=com.atlassian.jira.plug... ] Boris Unckel commented on WFCORE-4805: -------------------------------------- The solution is easy for initial setup: One has to conventionally configure the JRE with -Djava.security.policy=/pathToPolicy/security.policy Afterwards its still hard: The instrumentation of the javaAgents causes code without proper codeSource. I have written a dirty workaround - code with CodeSource.getLocation == null && classloader.contains("com.singularity") will not throw a security exception. I would be happy to get other suggestions - [~dmlloyd] ? > WildFly Security Manager does not act for javaagents > ---------------------------------------------------- > > Key: WFCORE-4805 > URL: https://issues.redhat.com/browse/WFCORE-4805 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Boris Unckel > Assignee: Darran Lofthouse > Priority: Major > > The WildFly Core Security Manager cares for modules and deployed artifacts. It offers a JavaEE 7 compliant solution to permissions.xml in META-INF of EARs/WARs. > Unfortunately it does not take care of javaagents, specified in > https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-su... > OpenSource: > https://inspectit.github.io/inspectit-ocelot/docs/getting-started/quick-s... > java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "setContextClassLoader")" in code source "(file:/opt/inspectit/inspectit-ocelot-agent-0.6.jar <no signer certificates>)" of "sun.misc.Launcher$AppClassLoader@18b4aac2") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192) > at java.lang.Thread.setContextClassLoader(Thread.java:1474) > at rocks.inspectit.ocelot.bootstrap.AgentManager.startOrReplaceInspectitCore(AgentManager.java:49) > at rocks.inspectit.ocelot.agent.AgentMain.startAgent(AgentMain.java:78) > at rocks.inspectit.ocelot.agent.AgentMain.lambda$premain$0(AgentMain.java:67) > at java.lang.Thread.run(Thread.java:748) > The specified JARs need AllPermission Config in the same way as container modules. > Other Examples for JavaAgents - closed source: > https://docs.appdynamics.com/display/PRO45/Java+Agent > https://docs.appdynamics.com/display/PRO45/JBoss+and+Wildfly+Startup+Sett... > https://docs.appdynamics.com/display/PRO45/Java+Security+Manager+Configur... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13122) Include MicroProfile Fault Tolerance subsystem in the default server profiles

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13122?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13122: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13012 (was: https://github.com/wildfly/wildfly/pull/13012, https://github.com/wildfly/wildfly/pull/13021) > Include MicroProfile Fault Tolerance subsystem in the default server profiles > ----------------------------------------------------------------------------- > > Key: WFLY-13122 > URL: https://issues.redhat.com/browse/WFLY-13122 > Project: WildFly > Issue Type: Task > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta2 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 20.0.0.Beta1 > > > MP FT can be included in the default profiles. The subsystem is very lightweight, the subsystem carries no configuration and the module dependencies are not added to the deployments if the application is not using FT annotations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13122) Include MicroProfile Fault Tolerance subsystem in the default server profiles

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13122?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-13122: --------------------------------------- We won't do this for 19.x, inclusion in the 20.x is still in the play. > Include MicroProfile Fault Tolerance subsystem in the default server profiles > ----------------------------------------------------------------------------- > > Key: WFLY-13122 > URL: https://issues.redhat.com/browse/WFLY-13122 > Project: WildFly > Issue Type: Task > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta2 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 20.0.0.Beta1 > > > MP FT can be included in the default profiles. The subsystem is very lightweight, the subsystem carries no configuration and the module dependencies are not added to the deployments if the application is not using FT annotations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13122) Include MicroProfile Fault Tolerance subsystem in the default server profiles

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13122?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13122: ---------------------------------- Fix Version/s: (was: 19.0.0.Beta3) > Include MicroProfile Fault Tolerance subsystem in the default server profiles > ----------------------------------------------------------------------------- > > Key: WFLY-13122 > URL: https://issues.redhat.com/browse/WFLY-13122 > Project: WildFly > Issue Type: Task > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta2 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 20.0.0.Beta1 > > > MP FT can be included in the default profiles. The subsystem is very lightweight, the subsystem carries no configuration and the module dependencies are not added to the deployments if the application is not using FT annotations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13185) Rest-client can't be used without opentracing subsystem present in config

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFLY-13185?page=com.atlassian.jira.plugi... ] Jean Francois Denise commented on WFLY-13185: --------------------------------------------- The problem is already in 18.0.1 (I just checked) so not a regression. I enlarged the scope, a default standalone.xml configuration without open-tracing shows the problem too. So we should have the problem in CD18/7.3 on openshift with the default config where open-tracing is not there by default. For galleon layers we are fine, observability is added as a whole, so jaxrs-server,observability (to get microprofile-config) works fine. > Rest-client can't be used without opentracing subsystem present in config > ------------------------------------------------------------------------- > > Key: WFLY-13185 > URL: https://issues.redhat.com/browse/WFLY-13185 > Project: WildFly > Issue Type: Bug > Components: MP REST Client > Reporter: Jean Francois Denise > Assignee: Alessio Soldano > Priority: Critical > Attachments: README, rest-reproducer.zip > > > Trying to provision the following set of galleon layers: > jaxrs ==> for jaxrs and rest-client > microprofile-config > I am getting an NPE. If open-tracing is provisioned along with jaxrs, no NPE and client injection works fine. > java.lang.NullPointerException > at org.jboss.resteasy.microprofile.client.RestClientExtension.extractBaseUri(RestClientExtension.java:40) > at org.jboss.resteasy.microprofile.client.RestClientExtension.registerRestClient(RestClientExtension.java:29) > 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.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:168) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:207) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:176) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:166) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:219) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:421) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:79) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:96) > 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) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13204) Move testsuite/layers in ts.layers profile

by Jean Francois Denise (Jira)

Jean Francois Denise created WFLY-13204: ------------------------------------------- Summary: Move testsuite/layers in ts.layers profile Key: WFLY-13204 URL: https://issues.redhat.com/browse/WFLY-13204 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Jean Francois Denise Assignee: Jean Francois Denise -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-169) Release Remoting JMX 3.0.4.Final

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/REMJMX-169?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved REMJMX-169. ------------------------------------- Resolution: Done > Release Remoting JMX 3.0.4.Final > -------------------------------- > > Key: REMJMX-169 > URL: https://issues.redhat.com/browse/REMJMX-169 > Project: Remoting JMX > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 3.0.4.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4866) Upgrade Undertow to 2.0.30.Final

by James Perkins (Jira)

James Perkins created WFCORE-4866: ------------------------------------- Summary: Upgrade Undertow to 2.0.30.Final Key: WFCORE-4866 URL: https://issues.redhat.com/browse/WFCORE-4866 Project: WildFly Core Issue Type: Component Upgrade Reporter: Bartosz Spyrko Assignee: Flavia Rainone Fix For: 11.0.0.Final Upgrade Undertow to 2.0.29.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4865) Upgrade Remoting JMX to 3.0.4.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-4865: ---------------------------------------- Summary: Upgrade Remoting JMX to 3.0.4.Final Key: WFCORE-4865 URL: https://issues.redhat.com/browse/WFCORE-4865 Project: WildFly Core Issue Type: Component Upgrade Components: JMX Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-169) Release Remoting JMX 3.0.4.Final

by Darran Lofthouse (Jira)

Darran Lofthouse created REMJMX-169: --------------------------------------- Summary: Release Remoting JMX 3.0.4.Final Key: REMJMX-169 URL: https://issues.redhat.com/browse/REMJMX-169 Project: Remoting JMX Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.4.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2020