Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.4.1.3
    • Component/s: JMX
    • Labels:
      None

      Description

      I don't believe that derby.system.jmx provides any benefit and is counter to the concept of using JMX for management.

      The one use case for it from DERBY-1387 is:
      Making the Derby JMX automatically available in the MBean server will make it impossible for the user to make some application with an embedded Derby db manageable thorugh JMX without also making Derby manageable thorugh JMX. I would think that this "all or nothing" granularity could be a problem for some applications. So we would need an explicit derby.system.jmx property for enabling the management service anyway.

      The functional spec contains no information as to why this is a useful feature.

      I wanted to separate out the discussion from the wider issues in DERBY-1387

        Issue Links

          Activity

          Hide
          Kristian Waagan added a comment -

          I notice there are still references to "derby.system.jmx" in Derby source code comments.

          Show
          Kristian Waagan added a comment - I notice there are still references to "derby.system.jmx" in Derby source code comments.
          Hide
          Daniel John Debrunner added a comment -

          Property removed with Revision: 631335

          Show
          Daniel John Debrunner added a comment - Property removed with Revision: 631335
          Hide
          Daniel John Debrunner added a comment -

          Thanks for the comments John.

          This concept of disabling user management of Derby and only allowing application level management is hard for me to grasp, especially without a security manager. Assuming applications will typically present a nice-console (using jmx beans under the covers) then they can easily hide any MBeans they don't won't to expose.

          Thus the concern would be two classes of users:

          • those smart enough to use a generic jmx console
          • those even smarter who can write jmx code.

          With Derby's MBeans a jmx client in a system without a security manager can monitor and control the jvm itself, create any MBeans that are available on the server's classpath to control any other software, thus it's not really just a Derby issue.

          My concern is that we might be solving this mythical use case at the expense of the more typical known use case, which is:

          • I have an intermittent problem in my running application, how can I see what is going on?
            Having to reboot to start JMX and then wait for the problem again does not seem acceptable.

          I agree that potentially reversing the state of the property, or to be clearer having an explicit property "derby.jmx.disable=true" could be an option, but only once there's some proven need for it. The functionality can be implemented today using the security manager, having a property that encourages use without a security manager to allow potentially insecure remote monitoring does not seem a good direction.

          I'll wait a few days and then proceed to remove derby.system.jmx.

          Show
          Daniel John Debrunner added a comment - Thanks for the comments John. This concept of disabling user management of Derby and only allowing application level management is hard for me to grasp, especially without a security manager. Assuming applications will typically present a nice-console (using jmx beans under the covers) then they can easily hide any MBeans they don't won't to expose. Thus the concern would be two classes of users: those smart enough to use a generic jmx console those even smarter who can write jmx code. With Derby's MBeans a jmx client in a system without a security manager can monitor and control the jvm itself, create any MBeans that are available on the server's classpath to control any other software, thus it's not really just a Derby issue. My concern is that we might be solving this mythical use case at the expense of the more typical known use case, which is: I have an intermittent problem in my running application, how can I see what is going on? Having to reboot to start JMX and then wait for the problem again does not seem acceptable. I agree that potentially reversing the state of the property, or to be clearer having an explicit property "derby.jmx.disable=true" could be an option, but only once there's some proven need for it. The functionality can be implemented today using the security manager, having a property that encourages use without a security manager to allow potentially insecure remote monitoring does not seem a good direction. I'll wait a few days and then proceed to remove derby.system.jmx.
          Hide
          John H. Embretsen added a comment -

          If we remove this system property and enable Derby JMX management by default, then the only recommended way for a user (admin) to allow JMX management of his application embedding Derby, but not Derby itself, is to use a security manager, correct?

          This means that if the user (admin) is not willing to use a security manager to limit JMX exposure, he must accept that valid JMX users may see and access Derby's MBeans. I don't see how this is much different from today, when a valid JMX user (client) may enable Derby's ManagementMBean programmatically even if the system property has not been set. This will in turn enable all relevant Derby MBeans.

          So, I think this is an acceptable approach.

          An alternative approach is to reverse the default value of the property, so that a user has to set it (to false) if he does not want to enable Derby's MBeans by default.
          Then, for example, JConsole users won't see MBeans related to Derby by default. It would still be possible to enable Derby's MBeans at runtime, using the ManagementMBean, so the usefulness of such a knob may be limited (it won't stop dedicated (and valid) JMX users from enabling the MBeans).

          At the moment I don't know of any other use cases supporting the need to enable Derby-JMX with a static knob.

          Show
          John H. Embretsen added a comment - If we remove this system property and enable Derby JMX management by default, then the only recommended way for a user (admin) to allow JMX management of his application embedding Derby, but not Derby itself, is to use a security manager, correct? This means that if the user (admin) is not willing to use a security manager to limit JMX exposure, he must accept that valid JMX users may see and access Derby's MBeans. I don't see how this is much different from today, when a valid JMX user (client) may enable Derby's ManagementMBean programmatically even if the system property has not been set. This will in turn enable all relevant Derby MBeans. So, I think this is an acceptable approach. An alternative approach is to reverse the default value of the property, so that a user has to set it (to false) if he does not want to enable Derby's MBeans by default. Then, for example, JConsole users won't see MBeans related to Derby by default. It would still be possible to enable Derby's MBeans at runtime, using the ManagementMBean, so the usefulness of such a knob may be limited (it won't stop dedicated (and valid) JMX users from enabling the MBeans). At the moment I don't know of any other use cases supporting the need to enable Derby-JMX with a static knob.
          Hide
          Daniel John Debrunner added a comment -

          Another thought is that we need to see MBeans as the mechanism to manage Derby, not just an api into existing management. Thus any application MBeans that are presenting a simplified/application specific view of Derby's management should be using Derby's MBeans to manage Derby. This requires that Derby's MBeans be available.

          Show
          Daniel John Debrunner added a comment - Another thought is that we need to see MBeans as the mechanism to manage Derby, not just an api into existing management. Thus any application MBeans that are presenting a simplified/application specific view of Derby's management should be using Derby's MBeans to manage Derby. This requires that Derby's MBeans be available.
          Hide
          Daniel John Debrunner added a comment -

          If an application is using a security manager then it provides a much more flexible mechanism to control which of Derby's MBeans are visible than the all or nothing approach of derby.system.jmx.
          An application using an embedded Derby with its own policy file can:

          • disable Derby from registering any MBeans
          • allow Derby to only register specific MBeans
          • allow authenticated JMX users to only perform specific actions on Derby's MBeans.

          Having Derby always attempt to register its MBeans (as if derby.system.jmx=true) i think provides a much more flexible environment, an application can provide limited or no management of Derby directly but also support a "drill-down" for more sophisticated users.

          The functionality being added in DERBY-3424 also allows the application to control the visibility of Derby's MBeans in a dynamic manner rather than the static manner of derby.system.jmx.

          Show
          Daniel John Debrunner added a comment - If an application is using a security manager then it provides a much more flexible mechanism to control which of Derby's MBeans are visible than the all or nothing approach of derby.system.jmx. An application using an embedded Derby with its own policy file can: disable Derby from registering any MBeans allow Derby to only register specific MBeans allow authenticated JMX users to only perform specific actions on Derby's MBeans. Having Derby always attempt to register its MBeans (as if derby.system.jmx=true) i think provides a much more flexible environment, an application can provide limited or no management of Derby directly but also support a "drill-down" for more sophisticated users. The functionality being added in DERBY-3424 also allows the application to control the visibility of Derby's MBeans in a dynamic manner rather than the static manner of derby.system.jmx.

            People

            • Assignee:
              Daniel John Debrunner
              Reporter:
              Daniel John Debrunner
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development