Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: derby-commits@db.apache.org
Date: Tue, 19 Feb 2008 19:10:46 -0000
Message-ID: <20080219191046.7270.88120@eos.apache.org>
Subject: [Db-derby Wiki] Update of "JMXSecurityExpectations" by DanDebrunner

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by DanDebrunner:
http://wiki.apache.org/db-derby/JMXSecurityExpectations

------------------------------------------------------------------------------
  === Local JMX ===
  A jvm may be setup to automatically provide local jmx access. In this case the OS user running the client must match the OS user that started the jvm being monitored. JMX authentication and access level does not apply here.
  ==== No Security Manager (local) ====
-  * With no security manager then the local jmx client (running as the same OS user as the virtual machine) may perform any JMX client operation including accessing any MBean including reading its attributes, writing its updatable attributes and invoking its operations, registering and unregistering MBeans, controlling the virtual machine etc.
+  * The local jmx client (running as the same OS user as the virtual machine) may perform any JMX client operation including accessing any MBean including reading its attributes, writing its updateable attributes and invoking its operations, registering and unregistering MBeans, controlling the virtual machine etc.
+  * Since there is no security manager then any action that requires a specific permission (e.g. shutdown Derby )would be allowed as well.
  ==== Security Manager (local) ====
-  * /!\ Haven't looked into how this works, what would the principal name be?
+  * It seems as though the local jmx client can perform any JMX operation such as getting attributes, invoking operations, registering MBeans etc. (i.e. I'm guessing that when run as the local os user the permissions come from the fact it's jvm system code that is performing jmx operations).
+  * The current access context has no Subject.
+  * If some action on a Derby MBean requires some security permission then that will fail unless the permission has been granted to Derby's code. E.g. an operation that fetches the system propertry "derby.system.home" succeeds, but reading a property derby.jar does not have permission to read fails. Reading the system property successfully did not require a privilege block (I presume because the calling code (jmx) is system code and granted all permissions).
  === Remote JMX ===
  Explicit actions are required by the JVM admin to:
   * Enable remote management via jmx (setting com.sun.management.jmxremote=true, com.sun.management.jmxremote.port)