qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell" <gemme...@dcs.gla.ac.uk>
Subject RE: [jira] Commented: (QPID-1469) AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Date Mon, 01 Dec 2008 01:24:07 GMT
One issue with making it on by default is that everyone will need to download the jmxremote_optional.jar
and add it to the classpath to start the broker, even for testing...which I believe is the
reason it was turned off by default in the first place, I recall seeing it in a commit message
when scouring the backlog previously. 

Regardless, it is probably worth maintaining the ability to connect with a normal RMIConnector
based jmx client when needed, which will require putting a fix in place for this issue, and
possibly addressing the current ability of an unauthenticated RMIConnector based client to
get access to the usermanagement area/mbean (which is a result of the rmiconnector server
being started directly using the mbeanserver, whereas the security enabled jmxmp based connector
server deals with an MBeanInvocationHandlerImpl mbeanserverforwarder proxy which checks the
user credentials).

Without taking the usermanagement access issue into account, one fix would simply be making
the AMQUserManagementMBean.getCurrentJMXUser() method handle the unathenticated rmi situation
by returning the equivalent of "unathenticated user", preventing the abortive jmxremote.access
file update that currently occurs and later results in the broker being unable to start. An
alternative would be to modify the JMXManagedObjectRegistry's use of the rmiconnector server
to be authenticated, giving the getCurrentJMXUser() something to retrieve and allowing use
of the MBeanInvocationHandlerImpl proxy to fix the usermanagement access issue as well. The
former is obviously a little hackish and no more secure than it is now, whereas the latter
will require implementation of a JAAS JMXAuthenticator (http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/JMXAuthenticator.html
) and is complicated by the choice between plain and hashed principal database files just
like the jmxmp based connection is, which requires the management console to know which type
of database the broker is using so that its sasl callback handler knows what to do.

-----Original Message-----
From: Marnie McCormack (JIRA) [mailto:qpid-dev@incubator.apache.org] 
Sent: 28 November 2008 11:30
To: qpid-dev@incubator.apache.org
Subject: [jira] Commented: (QPID-1469) AMQUserManagementMBean.getCurrentJMXUser no longer
returns a valid user[MESSAGE NOT SCANNED]

    [ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651527#action_12651527

Marnie McCormack commented on QPID-1469:

Discussed, think once QPID-794 fixed we should force authentication on with broker. We don't
really have a scenario where this doesnot apply even in dev. MR to raise other JIRAs to cover
changes required please ? Thanks vm.

> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>                 Key: QPID-1469
>                 URL: https://issues.apache.org/jira/browse/QPID-1469
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Management : JMX Console
>    Affects Versions: M4
>            Reporter: Martin Ritchie
>         Attachments: QPID-1469-NPE-AMQUMMBean.log
> Summary:
> Currently when the password and jmxremote.access files are updated the current username
is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing
any updates such as:
> Set Rights
> Delete User

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

View raw message