qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: [ANN] java RC3 available
Date Tue, 04 Sep 2007 07:10:22 GMT
On 03/09/07, Robert Greig <robert.j.greig@gmail.com> wrote:
> On 03/09/07, Martin Ritchie <ritchiem@apache.org> wrote:
>
> > > 1. Why do we have separate access and jmxremote.access files?
> > The jmxremote.access file provides access controls for the JMX
> > management console. Not all users need be listed in this section. This
> > is purely a permission assignment. No authentication credentials are
> > inferred or granted through this file. See 3 below.
>
> > The access file serves as an example Access Control file for the basic
> > FileAccessManager. Currently only you my only restrict read access to
> > a particular virtualhost as performing the controls on write requires
> > a check on every publish method which will affect performance. When
> > AMQP has ACL/RBAC which I believe is planed for 0_11 then this will be
> > updated accordingly.
>
> I don't think I quite understand. Is the the access control file not a
> permission assignment - permission to connect to a virtual host? If
> so, how does it differ conceptually from jmxremote.access?

The two files provide access to two different components they could be
combined but that would then require a new file format. The
jmxremote.access does not confer any permission to connect to the
broker for sending messages only the level of management control that
they have over the entire broker. The access file controls only
connections for broker access, sending and receiving via a set
virtualhost. You can think of it as access controls port 5672 and
jmxremote.access controls 8999.

> > > Is it deliberate that there are no default values for those users in
> > > the passwd file?
> >
> > It is simply a case that no-one has updated all the authentication
> > password file to contain these users.
>
> OK I think this should be updated for M2.1 then, since for a new user
> it looks like something isn't quite right.

agreed, though the management of users is definitely not recommended
in the default Apache shipped Qpid. The credentials are sent in clear
text across the wire.

> > > 3. The etc directory is somewhat confusing for a new user (or even
> > > me!). We have the following "passwd" files:
> >
> > We have a number of different authentication modules each use a
> > different file format.
> >
> > > md5passwd
> > For use with Base64MD5PasswordFile. File contains Base64 encoded
> > hashes of the users password.
> >
> > > passwd
> > For use with PlainPasswordFile. File contains plain text passwords
> >
> > > passwdVhost
> > For use with PlainPasswordVhostFile. File contains plain text
> > passwords and additional Virtualhost authorisation details.
>
> Why are authorisation details contained with the user database? Can
> you put the same authorisation data into the MD5 file?

They could be if you wrote a new PasswordFile class. I wrote the
PlainPasswordVHostFile as a demonstration of how you could combine the
PasswordFile and the AccessManager classes. The work on access control
stopped after I made the simple demonstrator as we need to wait for
the protocol WG to standardise the approach. The only alternative
AccessManager classes available are AllowAll and DenyAll, which don't
need any filesystem configuration.

> > > 4. What is qpid-server.conf.jpp for?
> >
> > I believe this is some configuration file for JProfiler. It shouldn't
> > be in the broker etc directory, it that is the case.
>
> OK, we should remove it for M2.1 then.

Indeed looking at the etc directory there are a few files that
probably shouldn't be there and certainly more documentation, around
the files that are there would be good.

> RG


-- 
Martin Ritchie

Mime
View raw message