You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@artemis.apache.org by "Gašper Čefarin (Jira)" <ji...@apache.org> on 2026/09/07 13:42:00 UTC

[jira] [Created] (ARTEMIS-6237) RBAC bugs when using com.sun.management.jmxremote JVM flags

Gašper Čefarin created ARTEMIS-6237:
---------------------------------------

             Summary: RBAC bugs when using com.sun.management.jmxremote JVM flags
                 Key: ARTEMIS-6237
                 URL: https://issues.apache.org/jira/browse/ARTEMIS-6237
             Project: Artemis
          Issue Type: Bug
          Components: Broker
    Affects Versions: 2.56.0
            Reporter: Gašper Čefarin
         Attachments: audit.log, etc.zip

[~brusdev] we talked about this a while ago - thank you for you earlier help. I'm providing all info I was able to gather here, along with the etc files to reproduce.

I think the most critical issue is that a user with read-only permissions is able to delete a queue, after {{com.sun.management.jmxremote}} flags are added to the JVM.

The etc files are provided, but here are the steps to reproduce to understand what was changed:
 * enable audit loggers in log4j2.properties
 * add a user to artemis-users and assign it the "users" role
 * add users role to HAWTIO_ROLES in artemis.profile
 * allow readonly access to users role in management.xml
 * in jolokia-access.xml allow * origins if needed
 * login to console with "user" user, password is "password"

 

With these changes, everything works as expected. User has readonly access, does not have any options to send messages to queues, or delete queues.

After that, add these java options (to artemis.profile)
{code:java}
JAVA_ARGS="$JAVA_ARGS -Dcom.sun.management.jmxremote.port=1098 -Dcom.sun.management.jmxremote.rmi.port=1097 -Dcom.sun.management.jmxremote.authenticate=false "{code}
 


possible additions:
{code:java}
JAVA_ARGS="$JAVA_ARGS -Dcom.sun.management.jmxremote.ssl=false  -Djava.rmi.server.hostname=10.10.10.11 "{code}

I use the above java options, in addition to "possible additions" for JMX monitoring. In my testing it turned out that the culprit is one of the first 3 options.

Offtopic: I'm able to use the same port for {{-Dcom.sun.management.jmxremote.port}} and {{-Dcom.sun.management.jmxremote.rmi.port}} in version {{{}2.53.0{}}}, but not in {{{}2.56.0


{}}}After adding the JVM flags, login to console and observe (at least) 2 symptoms:
1. "Send Message" can now be seen under the options for each queue (user cannot send the message though - a stack trace can be seen in audit logs)
2. "Delete" can now be seen under the options for each queue, and the user is able to actually delete the queues.{{{}

{}}}I'm copying Domenico's comments from our email conversation:



??... looking at the stack trace from the failed send, it is clear that ArtemisMBeanServerBuilder is not being initialized.??

??the stack trace is:??
??at java.management/javax.management.StandardMBean.invoke(StandardMBean.java:404)??
??at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:628)??
??at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:790)??
??at org.jolokia.service.jmx.handler.ExecHandler.doHandleSingleServerRequest(ExecHandler.java:115)??
??at org.jolokia.service.jmx.handler.ExecHandler.doHandleSingleServerRequest(ExecHandler.java:42)??

??while it should be:??
??at javax.management.StandardMBean.invoke(StandardMBean.java:405)??
??at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:803)??
??at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)??
??at java.lang.invoke.LambdaForm$DMH/0x00007fd5d052c000.invokeInterface(LambdaForm$DMH:-1)??
??at java.lang.invoke.LambdaForm$MH/0x00007fd5d052d800.invoke(LambdaForm$MH:-1)??
??at java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder:-1)??
??at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:157)??
??at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)??
??at java.lang.reflect.Method.invoke(Method.java:580)??
??at org.apache.activemq.artemis.core.server.management.ArtemisMBeanServerBuilder$MBeanInvocationHandler.invoke(ArtemisMBeanServerBuilder.java:93)??
??at jdk.proxy2.$Proxy33.invoke(Unknown Source:-1)??
??at org.jolokia.service.jmx.handler.ExecHandler.doHandleSingleServerRequest(ExecHandler.java:115)??
??at org.jolokia.service.jmx.handler.ExecHandler.doHandleSingleServerRequest(ExecHandler.java:42)??

??When accessControlList != null, the ManagementContext sets the system property javax.management.builder.initial to org.apache.activemq.artemis.core.server.management.ArtemisMBeanServerBuilder.??

??Something in your current configuration is preventing this initialization or a component is triggering the MBeanServerBuilder before the Artemis ManagementContext has a chance to set that system property.??

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@artemis.apache.org
For additional commands, e-mail: issues-help@artemis.apache.org