Re: [ANN] java RC3 available

[Robert Greig <ro...@gmail.com>]

On 30/08/07, Rajith Attapattu <ra...@gmail.com> wrote:

> I have tested the java binary with the python tests and it's fine.

I have started doing some brief sanity checking and it seems ok -
broker starts up fine.

I have been looking at improving our documentation on confluence and I
had a couple of questions that perhaps people could answer:

1. Why do we have separate access and jmxremote.access files?

2. On starting the broker the following warnings are printed:

2007-09-01 23:07:49,145 WARN  [main] access.AMQUserManagementMBean
(AMQUserManagementMBean.java:386) - Access rights contains user
'admin' but there is no authentication data for that user
2007-09-01 23:07:49,175 WARN  [main] access.AMQUserManagementMBean
(AMQUserManagementMBean.java:386) - Access rights contains user 'user'
but there is no authentication data for that user

Is it deliberate that there are no default values for those users in
the passwd file?

3. The etc directory is somewhat confusing for a new user (or even
me!). We have the following "passwd" files:

md5passwd
passwd
passwdVhost
qpid.passwd

Can someone explain the differences between these? I see md5passwd is
needed as an example md5 passwd file and passwd is for plain. But what
about the others?

4. What is qpid-server.conf.jpp for?

RG

Re: [ANN] java RC3 available

[Rajith Attapattu <ra...@gmail.com>]

Yep, I will create the final release artifacts, tags, release text and start
the vote thread soon after lunch.

Regards,

Rajith

On 9/6/07, Carl Trieloff <cc...@redhat.com> wrote:
>
> Robert Greig wrote:
> > On 06/09/07, Rajith Attapattu <ra...@gmail.com> wrote:
> >
> >> Is everybody happy?
> >>
> >
> > Ecstatic.
> >
> >
> >> Can we get the release rolling?
> >>
> >
> > Yes
> >
> > RG
> >
>
> ship it :-)
>
> Rajith, are you going to start the vote thread?
>
> Carl.
>
>
>

Re: [ANN] java RC3 available

[Carl Trieloff <cc...@redhat.com>]

Robert Greig wrote:
> On 06/09/07, Rajith Attapattu <ra...@gmail.com> wrote:
>   
>> Is everybody happy?
>>     
>
> Ecstatic.
>
>   
>> Can we get the release rolling?
>>     
>
> Yes
>
> RG
>   

ship it :-)

Rajith, are you going to start the vote thread?

Carl.

Re: [ANN] java RC3 available

[Robert Greig <ro...@gmail.com>]

On 06/09/07, Rajith Attapattu <ra...@gmail.com> wrote:
> Is everybody happy?

Ecstatic.

> Can we get the release rolling?

Yes

RG

Re: [ANN] java RC3 available

[Rajith Attapattu <ra...@gmail.com>]

Is everybody happy?

Can we get the release rolling?

Regards,

Rajith

On 9/4/07, Martin Ritchie <ri...@apache.org> wrote:
>
> On 04/09/07, Robert Greig <ro...@gmail.com> wrote:
> > On 04/09/07, Martin Ritchie <ri...@apache.org> wrote:
> >
> > > 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.
> >
> > I definitely think they should be combined. I think that
> > "authorisation" should be controlled in a single place to make it as
> > simple as possible for the user. It seems to me that we ended up with
> > two files for simplicity/speed of implementation rather than good
> > design.
>
> We haven't done a design :)
>
> > > 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.
> >
> > So which approach are we recommending for users? I am trying to put
> > together clear documentation on this.
>
> The Base64MD5 PF is the only one I would recommend. For any sort of
> secure usage as that is the only one that encrypts(albeit weakly) the
> password.
>
> Access Management needs more work so if you really need it then the
> only option currently is to run n brokers with different configs
>
> > RG
> >
>
>
> --
> Martin Ritchie
>

Re: [ANN] java RC3 available

[Martin Ritchie <ri...@apache.org>]

On 04/09/07, Robert Greig <ro...@gmail.com> wrote:
> On 04/09/07, Martin Ritchie <ri...@apache.org> wrote:
>
> > 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.
>
> I definitely think they should be combined. I think that
> "authorisation" should be controlled in a single place to make it as
> simple as possible for the user. It seems to me that we ended up with
> two files for simplicity/speed of implementation rather than good
> design.

We haven't done a design :)

> > 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.
>
> So which approach are we recommending for users? I am trying to put
> together clear documentation on this.

The Base64MD5 PF is the only one I would recommend. For any sort of
secure usage as that is the only one that encrypts(albeit weakly) the
password.

Access Management needs more work so if you really need it then the
only option currently is to run n brokers with different configs

> RG
>


-- 
Martin Ritchie

Re: [ANN] java RC3 available

[Robert Greig <ro...@gmail.com>]

On 04/09/07, Martin Ritchie <ri...@apache.org> wrote:

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

I definitely think they should be combined. I think that
"authorisation" should be controlled in a single place to make it as
simple as possible for the user. It seems to me that we ended up with
two files for simplicity/speed of implementation rather than good
design.

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

So which approach are we recommending for users? I am trying to put
together clear documentation on this.

RG

Re: [ANN] java RC3 available

[Martin Ritchie <ri...@apache.org>]

On 03/09/07, Robert Greig <ro...@gmail.com> wrote:
> On 03/09/07, Martin Ritchie <ri...@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

Re: [ANN] java RC3 available

[Robert Greig <ro...@gmail.com>]

On 03/09/07, Martin Ritchie <ri...@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?

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

> > 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?

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

RG

Re: [ANN] java RC3 available

[Martin Ritchie <ri...@apache.org>]

On 01/09/07, Robert Greig <ro...@gmail.com> wrote:
> On 30/08/07, Rajith Attapattu <ra...@gmail.com> wrote:
>
> > I have tested the java binary with the python tests and it's fine.
>
> I have started doing some brief sanity checking and it seems ok -
> broker starts up fine.
>
> I have been looking at improving our documentation on confluence and I
> had a couple of questions that perhaps people could answer:
>
> 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.


> 2. On starting the broker the following warnings are printed:
>
> 2007-09-01 23:07:49,145 WARN  [main] access.AMQUserManagementMBean
> (AMQUserManagementMBean.java:386) - Access rights contains user
> 'admin' but there is no authentication data for that user
> 2007-09-01 23:07:49,175 WARN  [main] access.AMQUserManagementMBean
> (AMQUserManagementMBean.java:386) - Access rights contains user 'user'
> but there is no authentication data for that user
>
> 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. The JMX console is not secure
unless using encryption on the JMX connection. You need the
jmxremote.jar to use a SASL connection which we cannot distribute as
its license is not an Apache friendly one. That coupled with the
Base64MD5 PasswordFile gives a reasonable level of security. Not great
but there you have it.

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

> qpid.passwd
This is a duplicate of md5passwd. I must have added this by mistake.


> Can someone explain the differences between these? I see md5passwd is
> needed as an example md5 passwd file and passwd is for plain. But what
> about the others?
>
> 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.

> RG
>


-- 
Martin Ritchie