db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Tue, 05 Feb 2008 14:52:08 GMT

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

John H. Embretsen commented on DERBY-1387:

@Kim: Thanks. As the spec stabilizes, it will probably become more clear what is needed wrt.

@Thomas: I agree that it could be clearer where the "home" of each part of derby's public
API is. The current public API is not very clear in this regard either, see e.g. http://db.apache.org/derby/javadoc/publishedapi/jdbc3/,
but I could try to clarify the jmx package(s) somewhat in this funcspec. As part of the documentation
effort, we should try to describe this in the package-summary of the new package(s) and in
other related Javadoc.


I suppose I was influenced by the current implementation when I specified a different package
for the Network Server MBean. This MBean was moved to the drda package because of some packaging
issue (according to comments in Jira), but if keeping all MBeans in the same package is practically
feasible I'm all for it. Since the MBeans are not directly related to JDBC I'm reluctant to
putting the others in the o.a.d.jdbc package.

    I see the point about exposing the derby.system.home property to JMX clients, but I don't
expect this to be a big issue, since when you enable JMX monitoring of your JVM, you usually
have access to lots of file system paths anyway (library path, boot class path, etc.). One
use case I think is valid is the need to read this property in a setting where you are running
Derby via third-party tools (IDEs, application servers, db management tools etc.), and you
don't necessarily know the working directory of the VM running the Derby system, or if derby.system.home
has been set automatically by such a tool. One way to find out where your databases (specified
with relative paths) end up on your file system is to check the value of derby.system.home.

     Not sure what the M stands for, to be honest. I was guessing "Managed Database", but
could be wrong. Perhaps the M should be removed unless someone can shed some light on this.
     SystemHome in MDatabaseMBean shouldn't be there. It's a bug in the funcSpec - it's not
available in the current implementation (patch 9).
     The AuthenticatedAsUser attribute could use a better description, for sure. It returns
the user name of the user who has been authenticated through JMX, i.e. the last valid user
name supplied as parameter to the authenticateAsUser() operation. If no user is authenticated
through JMX, the empty string is returned.


I'll update the funcspec later this week. I intend to incorporate the above feedback, but
I also think some details are needed wrt. MBean naming and (ObjectName) types and server domains.

Regarding the security issue mentioned in recent comments: 

     It could be argued that when you enable JMX management and monitoring you explicitly
expose your system for such access, and that if you want to control this you need to enable
JMX authentication (there is out-of-the-box support for the use of password files and SSL,
see http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html ).

I noticed, however, a note about a potential security vulnerability wrt. JMX password authentication
with J2SE 5.0 (see the above link, look for "WARNING"). A bit more work (mimicking out-of-the-box
management) is required for us to work around this...

I came across a blog post [1] which has some details around this (see its comments), and which
includes example use cases wrt. JMX authentication and authorization, which may be of help
if we don't decide to settle with the defaults. I've just skimmed through it so far, but perhaps
someone familiar with the current and soon-finished security features of Derby could take
a look at [1] and see if some kind of integration with existing features is desired and feasible?

For the short run, however, I propose simply going with the defaults, as long as we are clear
about the risks.

[1]: http://blogs.sun.com/lmalventosa/entry/jmx_authentication_authorization

> 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,
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.

View raw message