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

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARTEMIS-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ASF GitHub Bot updated ARTEMIS-6237:
------------------------------------
    Labels: pull-request-available  (was: )

> 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, JMX, Management
>    Affects Versions: 2.56.0
>            Reporter: Gašper Čefarin
>            Priority: Critical
>              Labels: pull-request-available
>         Attachments: audit.log, etc.zip
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> [~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:
> {code:java}
> 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){code}
> while it should be:
> {code:java}
> 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){code}
> 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