[jira] [Comment Edited] (AMQ-9300) hawtio console embedded in ActiveMQ classic showing only connect button
[
https://issues.apache.org/jira/browse/AMQ-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762351#comment-17762351
]
Nicolas Filotto edited comment on AMQ-9300 at 9/6/23 11:30 AM:
---
Actually, this problem is due to the fact that the default
{{jolokia-access.xml}} has been modified between 5.17.3 and 5.17.4 by AMQ-9201
for something more restrictive than it used to be indeed, the commands
{{write}} and {{exec}} are now forbidden by default. To fix your problem, you
will need to add at least {{exec}} to the list of commands allowed or simply
remove the restrictions on the list of commands allowed by removing it as next:
{code:xml}
org.apache.activemq:*
*
*
jolokia:type=Config
*
org.apache.logging.log4j2:*
*
*
com.sun.management:type=DiagnosticCommand
*
*
com.sun.management:type=HotSpotDiagnostic
*
*
jdk.management.jfr:type=FlightRecorder
*
*
{code}
was (Author: JIRAUSER285918):
Actually, this problem is due to the fact that the default
{{jolokia-access.xml}} has been modified between 5.17.3 and 5.17.4 by AMQ-9201
for something more restrictive than it used to be indeed, the commands
{{write}} and {{exec}} are now forbidden by default. To fix your problem, you
will need to add at least {{exec}} to the list of commands allowed or simply
remove the restrictions on the list of commands allowed by removing it.
> hawtio console embedded in ActiveMQ classic showing only connect button
> ---
>
> Key: AMQ-9300
> URL: https://issues.apache.org/jira/browse/AMQ-9300
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.17.4, 5.17.5, 5.18.2
>Reporter: Gianandrea Rigoni
>Priority: Major
> Attachments: 260776996-d66d2565-7534-4685-8e8a-4f3704c80df3.png
>
>
> hello folks
> *what worked*
> with versions
> ActiveMQ 5.17.3 and jetty JAAS jar 9.4.49.v20220914
> HAWTIO from version 2.16.3 to 2.17.6
> I am able +flawlessly to display HAWTIO+ console with all the queues
> (long ago I started to use instructions from
> https://bennet-schulz.com/2016/07/apache-activemq-and-hawtio.html)
> (I've LDAP plugin installed for the authentication)
> *now the problem*
> since AMQ 5.17.4 (jetty JAAS jar 9.4.50.v20221201) and HAWTIO from version
> 2.16.3 to 2.17.6:
> the only thing that I get in browser is shown in attached screenshot
> i.e. the add connection button
> also AMQ versions 5.17.5 and 5.18.2 show the same behaviour
> in both cases ("hawtio working" and "hawtio non working") AMQ broker and
> jolokia are functioning as expected)
> is this a bug or I missed some breaking changes?
> thanks for any advice
> best regards
> Gianandrea
> PS: not knowing/understanding where the problem is, I've reported it in
> hawtio project(https://github.com/hawtio/hawtio/issues/2917) too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (AMQ-9300) hawtio console embedded in ActiveMQ classic showing only connect button
[
https://issues.apache.org/jira/browse/AMQ-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762351#comment-17762351
]
Nicolas Filotto edited comment on AMQ-9300 at 9/6/23 11:31 AM:
---
Actually, this problem is due to the fact that the default
{{jolokia-access.xml}} has been modified between 5.17.3 and 5.17.4 by AMQ-9201
for something more restrictive than it used to be indeed, the commands
{{write}} and {{exec}} are now forbidden by default. To fix your problem, you
will need to add at least {{exec}} to the list of commands allowed or simply
remove the restrictions on the list of commands allowed by removing it as next:
{code:xml}
org.apache.activemq:*
*
*
jolokia:type=Config
*
org.apache.logging.log4j2:*
*
*
com.sun.management:type=DiagnosticCommand
*
*
com.sun.management:type=HotSpotDiagnostic
*
*
jdk.management.jfr:type=FlightRecorder
*
*
{code}
was (Author: JIRAUSER285918):
Actually, this problem is due to the fact that the default
{{jolokia-access.xml}} has been modified between 5.17.3 and 5.17.4 by AMQ-9201
for something more restrictive than it used to be indeed, the commands
{{write}} and {{exec}} are now forbidden by default. To fix your problem, you
will need to add at least {{exec}} to the list of commands allowed or simply
remove the restrictions on the list of commands allowed by removing it as next:
{code:xml}
org.apache.activemq:*
*
*
jolokia:type=Config
*
org.apache.logging.log4j2:*
*
*
com.sun.management:type=DiagnosticCommand
*
*
com.sun.management:type=HotSpotDiagnostic
*
*
jdk.management.jfr:type=FlightRecorder
*
*
{code}
> hawtio console embedded in ActiveMQ classic showing only connect button
> ---
>
> Key: AMQ-9300
> URL: https://issues.apache.org/jira/browse/AMQ-9300
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.17.4, 5.17.5, 5.18.2
>Reporter: Gianandrea Rigoni
>Priority: Major
> Attachments: 260776996-d66d2565-7534-4685-8e8a-4f3704c80df3.png
>
>
> hello folks
> *what worked*
> with versions
> ActiveMQ 5.17.3 and jetty JAAS jar 9.4.49.v20220914
> HAWTIO from version 2.16.3 to 2.17.6
> I am able +flawlessly to display HAWTIO+ console with all the queues
> (long ago I started to use instructions from
> https://bennet-schulz.com/2016/07/apache-activemq-and-hawtio.html)
> (I've LDAP plugin installed for the authentication)
> *now the problem*
> since AMQ 5.17.4 (jetty JAAS jar 9.4.50.v20221201) and HAWTIO from version
> 2.16.3 to 2.17.6:
> the only thing that I get in browser is shown in attached screenshot
> i.e. the add connection button
> also AMQ versions 5.17.5 and 5.18.2 show the same behaviour
> in both cases ("hawtio working" and "hawtio non working") AMQ broker and
> jolokia are functioning as expected)
> is this a bug or I missed some breaking changes?
> thanks for any advice
> best regards
> Gianandrea
> PS: not knowing/understanding where the problem is, I've reported it in
> hawtio project(https://github.com/hawtio/hawtio/issues/2917) too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
[
https://issues.apache.org/jira/browse/ARTEMIS-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762313#comment-17762313
]
Dries Harnie commented on ARTEMIS-4420:
---
Additional context and temporary workaround at
https://github.com/rh-messaging/artemis-prometheus-metrics-plugin/pull/18
> User authentication leaks into non-Artemis servlets
> ---
>
> Key: ARTEMIS-4420
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4420
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.30.0
>Reporter: Dries Harnie
>Priority: Minor
>
> ActiveMQ Artemis supports audit logs, which log all administrative actions
> that happen on the broker.
> These logs identify the "current user" for an administrative access [by one
> of two
> methods|https://github.com/apache/activemq-artemis/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/logs/AuditLogger.java#L67-L73]:
> # The {{Subject}} associated with the current security manager context, or
> # A {{{}ThreadLocal{}}}, which is set by JolokiaFilter as part of
> interaction with the admin console.
> For a non-Artemis servlet such as [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin],
> this {{ThreadLocal}} is set to whatever {{Subject}} made the previous request
> on this thread. This leads to situations where metric accesses are logged as
> being done by ghost users.
> To reproduce the issue:
> # Set up Artemis with the default admin/admin user and [the metrics
> plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin].
> # Enable audit logging ({{{}logger.audit_base{}}} should be at {{INFO}}
> level)
> # Tail -f the audit log and start the server
> # Log in to the admin console
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*}.
> # Access the metrics with eg {{{}curl http://localhost:8161/metrics/{}}}.
> # Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*},
> even though these requests are completely anonymous.
>
> I think the solution involves a modification to
> {{org.apache.activemq.artemis.component.JolokiaFilter}} but I do not
> understand the purpose of the code after the {{doFilter}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4420) User authentication leaks into non-Artemis servlets
Dries Harnie created ARTEMIS-4420:
-
Summary: User authentication leaks into non-Artemis servlets
Key: ARTEMIS-4420
URL: https://issues.apache.org/jira/browse/ARTEMIS-4420
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 2.30.0
Reporter: Dries Harnie
ActiveMQ Artemis supports audit logs, which log all administrative actions that
happen on the broker.
These logs identify the "current user" for an administrative access [by one of
two
methods|https://github.com/apache/activemq-artemis/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/logs/AuditLogger.java#L67-L73]:
# The {{Subject}} associated with the current security manager context, or
# A {{{}ThreadLocal{}}}, which is set by JolokiaFilter as part of
interaction with the admin console.
For a non-Artemis servlet such as [the metrics
plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin], this
{{ThreadLocal}} is set to whatever {{Subject}} made the previous request on
this thread. This leads to situations where metric accesses are logged as being
done by ghost users.
To reproduce the issue:
# Set up Artemis with the default admin/admin user and [the metrics
plugin|https://github.com/rh-messaging/artemis-prometheus-metrics-plugin].
# Enable audit logging ({{{}logger.audit_base{}}} should be at {{INFO}} level)
# Tail -f the audit log and start the server
# Log in to the admin console
# Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*}.
# Access the metrics with eg {{{}curl http://localhost:8161/metrics/{}}}.
# Observe that a lot of audit logs fly by for {*}admin(amq)@127.0.0.1{*}, even
though these requests are completely anonymous.
I think the solution involves a modification to
{{org.apache.activemq.artemis.component.JolokiaFilter}} but I do not understand
the purpose of the code after the {{doFilter}} invocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (AMQ-9300) hawtio console embedded in ActiveMQ classic showing only connect button
[
https://issues.apache.org/jira/browse/AMQ-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762351#comment-17762351
]
Nicolas Filotto commented on AMQ-9300:
--
Actually, this problem is due to the fact that the default
{{jolokia-access.xml}} has been modified between 5.17.3 and 5.17.4 by AMQ-9201
for something more restrictive than it used to be indeed, the commands
{{write}} and {{exec}} are now forbidden by default. To fix your problem, you
will need to add at least {{exec}} to the list of commands allowed or simply
remove the restrictions on the list of commands allowed by removing it.
> hawtio console embedded in ActiveMQ classic showing only connect button
> ---
>
> Key: AMQ-9300
> URL: https://issues.apache.org/jira/browse/AMQ-9300
> Project: ActiveMQ
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 5.17.4, 5.17.5, 5.18.2
>Reporter: Gianandrea Rigoni
>Priority: Major
> Attachments: 260776996-d66d2565-7534-4685-8e8a-4f3704c80df3.png
>
>
> hello folks
> *what worked*
> with versions
> ActiveMQ 5.17.3 and jetty JAAS jar 9.4.49.v20220914
> HAWTIO from version 2.16.3 to 2.17.6
> I am able +flawlessly to display HAWTIO+ console with all the queues
> (long ago I started to use instructions from
> https://bennet-schulz.com/2016/07/apache-activemq-and-hawtio.html)
> (I've LDAP plugin installed for the authentication)
> *now the problem*
> since AMQ 5.17.4 (jetty JAAS jar 9.4.50.v20221201) and HAWTIO from version
> 2.16.3 to 2.17.6:
> the only thing that I get in browser is shown in attached screenshot
> i.e. the add connection button
> also AMQ versions 5.17.5 and 5.18.2 show the same behaviour
> in both cases ("hawtio working" and "hawtio non working") AMQ broker and
> jolokia are functioning as expected)
> is this a bug or I missed some breaking changes?
> thanks for any advice
> best regards
> Gianandrea
> PS: not knowing/understanding where the problem is, I've reported it in
> hawtio project(https://github.com/hawtio/hawtio/issues/2917) too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4421) Page Counters are not working before rebuild is done
Clebert Suconic created ARTEMIS-4421: Summary: Page Counters are not working before rebuild is done Key: ARTEMIS-4421 URL: https://issues.apache.org/jira/browse/ARTEMIS-4421 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.30.0 Reporter: Clebert Suconic Fix For: 2.31.0 Page Counters will not work correctly until rebuild is done. We set the snapshot values, but because the queues were not marked not empty they are not used until the rebuild is done. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4174) JMX RMI connector-ports limited to localhost listen for remote connections
[
https://issues.apache.org/jira/browse/ARTEMIS-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762434#comment-17762434
]
ASF subversion and git services commented on ARTEMIS-4174:
--
Commit 9864e005d2db63531827588f1cd55082f9d7c505 in activemq-artemis's branch
refs/heads/main from Robbie Gemmell
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=9864e005d2 ]
ARTEMIS-4174: test is verifying hostname detail, so use floating ports to avoid
sporadic bind failures that are happening
> JMX RMI connector-ports limited to localhost listen for remote connections
> --
>
> Key: ARTEMIS-4174
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4174
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.28.0
>Reporter: Marvin Blauth
>Priority: Minor
> Fix For: 2.31.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The documentation in docs/user-manual/en/management.md allows the
> interpretation that setting the connector-host of the "" element
> in management.xml could be used to limit the exposure of the JMX RMI TCP port
> to localhost only. It says the "connector-host" attribute for the
> "" element could be used to specify "the host to expose the agent
> on". Depending on the definition of the word "exposure" this may not be the
> case.
> The documentation in examples/features/standard/jmx-ssl/readme.md in contrast
> says 'To access this MBeanServer remotely, add the following to the
> management.xml configuration: connector-host="localhost"/>'. This is describing a remote connection using
> "localhost" in "connector-host", which at least would be in violation of my
> understanding of the notion of limiting exposure.
> Setting "connector-host" to "localhost" (which is the default) in fact leads
> to opening a port listening to all incoming external requests. This is due to
> creating an RMI registry in
> org.apache.activemq.artemis.core.server.management.RmiRegistryFactory.init()
> without providing a SocketFactory limiting the host.
> Example netstat output for such a setup:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 :::1099 :::*LISTEN
> {noformat}
> It is unclear to me what the intended behavior is in terms of open TCP
> sockets. I assume a limitation of the exposure should be possible in my
> following suggestion for a solution (I can provide a patch, if this approach
> is to be taken).
>
> *Possible solution (if indeed desired this way)*
> If one wanted to expose the registry to the specified host only (not clear if
> that is the intended behavior as described above), a custom
> RMIServerSocketFactory could be created instead that only creates
> ServerSockets limited to the host name provided by the user in the
> "connector-host" attribute. This would then lead to the service only
> listening to the IP associated with the provided host name.
> Example netstat output using the same configuration but with the described
> change to the RmiRegistryFactory, showing the expected output:
> {noformat}
> $ netstat -tan | grep 1099 | grep LISTEN
> tcp6 0 0 127.0.0.1:1099 :::*LISTEN
> {noformat}
> A downside of this approach is that currently "localhost" seems to be the
> default value for connector-host if not explicitly set, see
> org.apache.activemq.artemis.core.config.JMXConnectorConfiguration. So a
> change in the semantics of the connector-host attributed would lead to a
> change of the behavior of users using this value implicitly. I assume that
> currently a remote login is not possible anyway if "localhost" is set, even
> though it is possible to initiate a TCP connection to the service, but I did
> not investigate this (note that this would be in contrast to the
> documentation cited above, so it should probably be investigated). If the
> assumption is indeed correct, the change in semantics should not negatively
> affect users.
>
> *Workaround*
> As workaround external connection attempts to the RMI ports can of course be
> dropped using a firewall.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4418: Description: Following up on ARTEMIS-4410, message order is necessary to make sense of the openwire consumer close lastDeliveredSequence id, when order is compromised the delivery count on prefetched messages can get incremented in error. The root cause is the use of the persistence id, or store order, which is itself loose. It would be better if the sequence id was directly related to the consumer delivered list and independent of total queue order. was: Following up on ARTEMIS-4410, message order is necessary to make sense of the openwire consumer close lastDeliveredSequence id, when order is compromised the delivery count on prefetched messages can get incremented in error. We should use the default (core) delivery semantics of treating credit or delivered or prefetched messages as not delivered on non exclusive queues. Only on an exclusive queue will we respect the lastDeliveredSequenceId > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > The root cause is the use of the persistence id, or store order, which is > itself loose. It would be better if the sequence id was directly related to > the consumer delivered list and independent of total queue order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARTEMIS-4418) openwire lastDeliveredSequenceId depends on message order, it should not
[ https://issues.apache.org/jira/browse/ARTEMIS-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4418: Summary: openwire lastDeliveredSequenceId depends on message order, it should not (was: openwire lastDeliveredSequenceId depends on message order, should only be respected on an exclusive queue) > openwire lastDeliveredSequenceId depends on message order, it should not > > > Key: ARTEMIS-4418 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4418 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.30.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > > Following up on ARTEMIS-4410, message order is necessary to make sense of the > openwire consumer close lastDeliveredSequence id, when order is compromised > the delivery count on prefetched messages can get incremented in error. > We should use the default (core) delivery semantics of treating credit or > delivered or prefetched messages as not delivered on non exclusive queues. > Only on an exclusive queue will we respect the lastDeliveredSequenceId -- This message was sent by Atlassian Jira (v8.20.10#820010)
