Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <22481451.1201894388343.JavaMail.jira@brutus>
Date: Fri, 1 Feb 2008 11:33:08 -0800 (PST)
From: "John H. Embretsen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
In-Reply-To: <4163741.1149764849905.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564898#action_12564898 ] 

John H. Embretsen commented on DERBY-1387:
------------------------------------------

Thanks for taking a look at this, Dan - the more eyes on this the better.

> 1) Is a derby.system.jmx needed? What would be the downside of always having the jmx beans available, or available if the jvm has jmx running?
> This may depend on security issues, I haven't looked at that in detail yet.

Potential new and unknown security risks is my primary concern at the moment, weighing in against enabling JMX by default. I believe that a portion of the security risks introduced with this feature have not been identified and evaluated fully yet. Other than that I have no big concerns about enabling it by default. The performance penalty should be negligible, at least. It should, however, be possible for the paranoid user to disable the Management Service, I think. Then I guess such a property would be needed anyway...?

> 2) In the "Enabling Management Features" section, are the com.sun properties standard JMX, or are they specific to Sun's implementation of the JVM? useful to state this in the specification, so that any user documentation reflects reality.

Good question, I've been wondering that myself. I cannot find any reference to those properties in the JMX specs (but maybe I didn't look hard enough). I have seen the com.sun.management.jmxremote properties in used in reference to the newer JVMs from other vendors than Sun, such as IBM and BEA (JRockit), so it seems to be a de facto standard at least...

> 3) The spec says that classes in org.apache.derby.impl.services.mbeans. will be added to the public api. The 'org.apache.derby.impl.' set of packages is for implementations of internal apis (o.a.d.iapi). If these classes are external then they need to be moved to a new package. o.a.d.jmx?

I see, makes sense. I think moving the public interfaces to a new package is something that should be considered for the next version of the patch.

> As a minor point I wouldn't have Derby in the name of these classes.

That is probably redundant, yes. DerbySystemMBean should be renamed to SystemMBean in the next version of the patch.

> Can authenticateAsUser(String user, String password) in the database bean be explained more fully?
> Is there a single database bean for a database, or is a new one created for each jmx session or connection (not sure of correct term here)?

There is currently a single MDatabaseMBean per database.

> If there is a single bean for a database then this authenticateAsUser seems to open up a big security hole, once this operation is made any other valid jmx user can reconfigure the database, even if they don't have valid database permissions.

Correct, that is one of the issues I had in mind when I noted that the current patch "lacks a few essential security measures".
 
> Or can the authentication information be limited to a single jmx session, even with a single bean?

Not with the current implementation, but perhaps it is possible to implement some kind of session handling to support something like this? Not sure if the previous contributors to this feature have given this any thought...

> Also, why is authenticateAsUser limited to the BUILTIN authentication scheme, since it is just providing user/password to a connection request won't it be independent of the authentication scheme in effect?

Right, I believe this is a cut&paste error in the funcspec. All it does is to establish a regular JDBC connection using DriverManager. I'll rectify it in the next version. Thanks for noticing!


> Add JMX extensions to Derby
> ---------------------------
>
>                 Key: DERBY-1387
>                 URL: https://issues.apache.org/jira/browse/DERBY-1387
>             Project: Derby
>          Issue Type: New Feature
>          Components: Services
>            Reporter: Sanket Sharma
>            Assignee: John H. Embretsen
>         Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff, DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff, DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip, DERBY-1387-7.zip, DERBY-1387-8.zip, DERBY-1387-9.diff, DERBY-1387-9.stat, derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, jmxFuncspec.html, Requirements for JMX Updated.html, Requirements for JMX.html, Requirements for JMX.zip
>
>
> This is a draft requirement specification for adding monitoring and management extensions to Apache Derby using JMX. The requirements document has been uploaded on JIRA as well as the Derby Wiki page at http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX
> Developers and Users are requested to please look at the document (feature list in particular) and add their own rating to features by adding a coloumn to the table.
> Comments are welcome.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.