Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6714966

Permissions checks in registerMBean and createMBean are inconsistent.

    Details

      Description

      The Javadoc in MBeanServer says that the permission you need when calling createMBean corresponds to the permissions you need for instantiate, plus the permission you need for registerMBean.

      Unfortunately this is not exactly what is implemented. If we call clazz the MBean class, className[param] the className passed as parameter to createMBean/instantiate and
      className[info] the className returned by MBeanInfo.getClassName(), objectName[param] the ObjectName passed as parameter to createMBean/registerMBean, and objectName[instance] the actual ObjectName of the MBean, as returned in the ObjectInstance by createMBean/registerMBean, then the permission needed are:

      1) for instantiate:
         MBeanPermission(className[param],null,null,"instantiate")

      2) for registerMBean:
         clazz.getProtectionDomain() must imply MBeanTrustPermission("register")
         MBeanPermission(className[info],null,objectName[param],"registerMBean")
         MBeanPermission(className[info],null,objectName[instance],"registerMBean")

      3) for createMBean (inconsistent - not = to instantiate+registerMBean):
         MBeanPermission(className[param],null,null,"instantiate")
         clazz.getProtectionDomain() must imply MBeanTrustPermission("register")
         MBeanPermission(className[param],null,objectName[param],"registerMBean")
         MBeanPermission(className[info],null,objectName[instance],"registerMBean")

      => create MBean should be fixed so that its 3rd permission check above uses
         className[info] - as in registerMBean, and not className[param], as it currently
         does.

      (the other alternative would be to change the spec of createMBean & document the
       current behaviour, as changing the behaviour & spec of registerMBean would be yet
       a bigger - and more risky change).

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              dfuchs Daniel Fuchs
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: