Use case: Allow an admin to restrict the scope of available queries for finding beans. Also allow the scope to be restricted per operation. Done by allowing for a servlet init parameter or a servlet context init param. Naming of the parameter is the same (except the context version has a "JMXProxyServlet." prefix to the name) By allowing servlet context init param, then the manager.xml context file can be updated instead of the more risky (when versions update) server admin change of web.xml The value is a comma or whitespace separated list of allowable regex's to be checked against the query param before running the JMX query. This can allow the effective disable of set or generic query while preserving get to a finite namespace and invoke to just garbage collection. (Per example in docs) Patch preview for the basic concept (disclaimer: untested but up for ideas in renaming the param names or general approach) https://github.com/apache/tomcat/compare/main...funkman:jmx_lockdown?expand=1
This enhancement is risky since if there's a problem somehow it will be an immediate RCE CVE (once people start assuming they can safely expose JMX to the world).
100% agreed. I definitely need to add more to the docs to call this out. For example - in manager-howto.xml - one tweak was the say WARNING instead of NOTE. I was hoping to hit the use case of people using JMXProxy for monitoring and this is a flexible way to limit usage to the "get' operations as well as limit the scope for what get can see. I wasn't sure if this was an OK approach to limit usage as compared to other possibilities. For example: another approach is to moving "op" query string to a path. In which case: Its easier to add different roles in each of those paths. (But this approach would have backwards compatibility challenges)
If we want to support provision of metrics to unprivileged or minimally privileged users then I think we should consider a mechanism that doesn't involve those users providing the JMX query that gets executed. For example, a new status servlet could be implemented that provides system admin selected metrics in a single page - possibly in JSON format. JMX is likely to be the underlying mechanism used to populate the results and a set of JMX queries could be used to configure it but all end users would be able to do is request the page.
True - if that is the case - there is this: /manager/status?XML=true which is xml, not JSON. I'd wonder what additional metrics users were interested that are missing. (As well as if its worth it to optionally exclude processes currently being requested)