Bug ID: JDK-6714954 Description of MBeanPermission checking in MBeanServer javadoc is inacurrate

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 7
7 b43Fixed

1) regarding queryMBeans/queryNames:
====================================

the doc says:

----------------------------------------------------------------
For the queryMBeans method, the caller's permissions must imply MBeanPermission(mbeanServerName, null, null, name, "queryMBeans"). Additionally, for each MBean that matches name, if the caller's permissions do not imply MBeanPermission(mbeanServerName, className, null, name, "queryMBeans"), the MBean server will behave as if that MBean did not exist.

--- [snip] ---

For the queryNames method, the checks are the same as for queryMBeans except that "queryNames" is used instead of "queryMBeans" in the MBeanPermission objects. Note that a "queryMBeans" permission implies the corresponding "queryNames" permission.
----------------------------------------------------------------

In fact it should say that queryMBeans checks for:
MBeanPermission(mbeanServerName, null, null, null, "queryMBeans").
and not for
MBeanPermission(mbeanServerName, null, null, name, "queryMBeans").

2) regarding className
======================

The javadoc of MBeanServer says that the className used to check
permissions is always the value returned by getMBeanInfo().getClassName().
This is not true for "instantiate", where the classname is the classname
passed as parameter to instantiate (or createMBean, when the "instantiate"
permission is checked by "createMBean").

EVALUATION In fact the sentence in question for queryNames and queryMBeans should not say null. Two checks are made: the first one checks whether you can do queryNames at all, and specifies null. The second one is made for every MBean found, and specifies the name of that MBean, to decide whether you can see it. The specification of this second check should not say "name", which is the queryNames parameter that is usually a parameter. We need to introduce a variable, say n, that is the name of each MBean found. The second problem was fixed as part of the fix for CR 5072476 (which added namespaces).

05-12-2008

EVALUATION There doesn't seem to be any danger that anybody is depending on the documented behaviour for queryNames, which makes no sense. The name parameter to queryNames and queryMBeans is nearly always an ObjectName pattern, and the documentation for MBeanPermission.implies and ObjectName.apply makes it clear that if the permission checked were really this pattern then you would only have permission to do the query if you had an MBeanPermission where the ObjectName exactly matched that pattern. For example, if you had this permission... MBeanPermission "[*:*]", "queryNames" ...then you would not be allowed to do this operation... queryNames(new ObjectName("domain:*"), null) ...because the pattern "domain:*" is not exactly equal to the pattern "*:*". Nobody would want that behaviour so we should just fix the documentation. Concerning the classname in instantiate, obviously the class in question should be the one named in the instantiate call, and not the one returned by the MBeanInfo of the object once it is instantiated. Otherwise the instantiation would have to be done before the permission could be checked, and besides the instantiate method can instantiate objects that are not MBeans and therefore do not have MBeanInfo. So in both cases we should just fix the documentation in the obvious way. Since we are just changing the spec to match the implementation, there is no risk of breaking existing code.

16-06-2008