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: JMXManagedObjectRegistry and AMQUserManagementMBean can potentially use different PrincipalDatabases
Date Mon, 01 Dec 2008 21:52:33 GMT
Mmm, had a closer look...still not sure it's quite right, though I may be
totally missing something :) 

I can see its reasonable for AMQP related stuff to use one principal
database and management stuff to use another, obviously...but here we have 2
broker management related areas that work together in establishing and
controlling jmx connections, but can potentially be using different
principal databases. Looking more closely at the methods in
AMQUserManagementMBean, it treats the existence of a user/password in the PD
it uses as being very related to the contents of the jmxremote.access file
used to determine what people can do in the management console. All the
create/delete/set rights methods in AMQUserManagementMBean update the
jmxremote.access file in accordance to the contents of or any changes they
make in the PD AMQUserManagementMBean is using. However, if that is not the
same PD that JMXManagedObjectRegistry is using, then the rights
AMQUserManagementMBean alters or checks in jmxremote.access have no
relevance to the user details that exist in the PD JMXManagedObjectRegistry,
which are what is being used to authenticate the management console
connections in the first place and are the user details the jmxremote.access
file is used to check rights for by the MBeanInvocationHandlerImpl proxy.
That doesn't make sense to me, if the idea is to be able to split management
authentication off entirely from other authentication it doesnt work as-is,
and it also opens a possible hole in the management rights/authentication

For example, I add 2 Base64MD5 PDs to the config in such a way that the 2
areas will use different PDs (setting the
broker.security.jmx.principal-database element to the second Base64MD5 PD
achieves this, there are lots of other ways of course). I then log in with
user details held in the first PD that JMXManagedObjectRegistry is using,
and rights held in jmxremote.access. I add a new user with <whatever> rights
using AMQUserManagementMBean through the console and it would create those
user details in the principal database AMQUserManagementMBean is using and
assign those rights in jmxremote.access. As far as connecting with a
management console goes I would still be unable to as the PD that
JMXManagedObjectRegistry is using still wouldn't know those user
details...unless of course the username happened to coincide with someone
else's username in the other PD, in which case they now have unintended
management access no matter what their password is, oops. The reverse is
also an issue, if I delete an account with AMQUserManagementMBean using one
PD, the JMXManagedObjectRegistry would still happily let me connect if my
details match those in the PD that it is using, as they haven't been
deleted...but my jmxremote.access rights will have been deleted, which might
be a problem.

So I still think that JMXManagedObjectRegistry should be picking its PD
based on the broker.security.jmx.principal-database element from the
configuration file, as AMQUserManagementMBean does. If not, id say there are
other issues to address.

Well thats a far bigger email than I originally intended...but I loathe to
trim it down, so if you made it this far, sorry :)


-----Original Message-----
From: aidan.skinner@gmail.com [mailto:aidan.skinner@gmail.com] On Behalf Of
Aidan Skinner
Sent: 01 December 2008 09:32
To: qpid-dev@incubator.apache.org
Subject: Re: JMXManagedObjectRegistry and AMQUserManagementMBean can
potentially use different PrincipalDatabases[MESSAGE NOT SCANNED]

On Mon, Dec 1, 2008 at 2:47 AM, Robbie Gemmell <gemmellr@dcs.gla.ac.uk>

> Noticed something earlier when playing with different database types. The
> JMXManagedObjectRegistry and AMQUserManagementMBean classes related to the
> JMX management features dont use the same terms of selection/assignment
> the PrincipalDatabase they should use, and so can potentially use
> databases. This would result in management console connections being
> authenticated through one principal database, and the console's
> usermanagement capabilities modifying a different principal database. Is
> that by design (eg, allowing JMX management specific accounts??) or is it
> option number 2, a bug ? Thought id enquire to make sure before cluttering
> the JIRA J

This by design. Admin rights and AMQP rights are different concepts.

> AMQUserManagementMBean has its principal database set according to the
> broker.security.jmx.principal-database element from the configuration
> and is set at startup by the ConfigurationFilePrincipalDatabaseManager
> .initialisePrincipalDatabase() method, just before the
> JMXManagedObjectRegistry is created, which itself acquires a list of all
> principal databases from the application registry and loops through them,
> selecting either the first Base64MD5PasswordFilePrincipalDatabase it
> or if it find none then uses the last PlainPasswordFilePrincipalDatabase
> encounters.

I've always thought that this was a rather weird way of doing it, we
should clean that up and make it more obvious.

- Aidan

Apache Qpid - World Domination through Advanced Message Queueing
"Have we anything resembling a plan?" "Mm-hm. Ride till we find
them... and kill them all." - The 13th Warrior

View raw message