You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org> on 2010/04/23 13:52:51 UTC
[jira] Created: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Update ACL file syntax to be clearer and add extra operations
-------------------------------------------------------------
Key: QPID-2539
URL: https://issues.apache.org/jira/browse/QPID-2539
Project: Qpid
Issue Type: Task
Components: Java Broker
Reporter: Andrew Kennedy
Fix For: 0.7
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Marnie McCormack <ma...@googlemail.com>.
Thanks Rajith - sounds like a good plan.
Appreciate your time,
Marnie
On Thu, Jun 3, 2010 at 3:41 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> On Thu, Jun 3, 2010 at 10:32 AM, Marnie McCormack
> <ma...@googlemail.com> wrote:
> > Hi Rajith,
> > I'll let you decide - but could you assign it over to yourself if you are
> > progressing ?
> >
> > As an aside, I don't think its practicable to be debating designs for
> such
> > lengthy periods of time. Context switching is waste, and I think the
> elapsed
> > time for design decisions on Apache represents a key challenge to
> productive
> > development process.
>
> I agree with you and I have been affected with the same in the past.
> I was pretty swamped with an internal release, but will make every
> effort to have something tomorrow so we could make good progress.
> I appreciate the patience and the willingness to discuss by all
> concerned parties.
> There have been many features that were slapped in without much
> discussion, so hopefully the time spent on this will bear fruit in a
> better design that is agreeable to everybody concerned.
>
> >
> > Thanks,
> > Marnie
> > On Thu, Jun 3, 2010 at 3:08 PM, Rajith Attapattu <ra...@gmail.com>
> wrote:
> >
> >> Marine,
> >>
> >> I didn't see any commits related to this JIRA, so perhaps there are
> >> related JIRA's to this which have commits under them?
> >> Also there are no patches attached to this JIRA either.
> >> If I am not mistaken, this JIRA was created mostly to discuss the
> >> proposal. So since it hasn't reached a conclusion, I think it's best
> >> to keep the JIRA open.
> >>
> >> I think it's probably useful to continue using this JIRA to thrash out
> >> the proposal to ensure we capture all the history.
> >> And then maybe when we agree on a concrete proposal we could create
> >> JIRA's for specific areas that will have commits under them?
> >> Is that fine with you ?
> >>
> >> Regards,
> >>
> >> Rajith
> >>
> >> On Thu, Jun 3, 2010 at 9:47 AM, Marnie McCormack
> >> <ma...@googlemail.com> wrote:
> >> > Hi Rajith,
> >> >
> >> > Would it be possible to separate out the remaing areas/items you'd
> like
> >> to
> >> > make a proposal on ?
> >> >
> >> > I noticed you suggested this approach on the JIRA (11th May) and ity'd
> be
> >> > useful to be able to focus any frrther work on the specific items
> you'd
> >> like
> >> > to see. This JIRA is already a monster and the patches have been
> reviewed
> >> > and committed.
> >> >
> >> > I'm sure Andrew will be responsive to you and any proposal.
> >> >
> >> > How does that sound ?
> >> >
> >> > Regards
> >> > Marnie
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Jun 3, 2010 at 2:38 PM, Rajith Attapattu (JIRA) <
> >> > qpid-dev@incubator.apache.org> wrote:
> >> >
> >> >>
> >> >> [
> >> >>
> >>
> https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875107#action_12875107
> >> ]
> >> >>
> >> >> Rajith Attapattu commented on QPID-2539:
> >> >> ----------------------------------------
> >> >>
> >> >> Marnie,
> >> >>
> >> >> All though we discussed, I do not think we agreed on a concrete
> proposal
> >> >> yet.
> >> >> I believe there are still some open questions that didn't quite get
> >> >> resolved.
> >> >>
> >> >> I am also working on a proposal which I am hoping to get out by
> >> tomorrow.
> >> >> So I'd appreciate if we keep this JIRA open until we get some sort of
> >> >> agreement.
> >> >>
> >> >> Regards,
> >> >>
> >> >> Rajith
> >> >>
> >> >> > Update ACL file syntax to be clearer and add extra operations
> >> >> > -------------------------------------------------------------
> >> >> >
> >> >> > Key: QPID-2539
> >> >> > URL:
> https://issues.apache.org/jira/browse/QPID-2539
> >> >> > Project: Qpid
> >> >> > Issue Type: Sub-task
> >> >> > Components: Java Broker
> >> >> > Reporter: Andrew Kennedy
> >> >> > Fix For: 0.7
> >> >> >
> >> >> > Attachments: acl.txt
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> This message is automatically generated by JIRA.
> >> >> -
> >> >> You can reply to this email to add a comment to the issue online.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> Apache Qpid - AMQP Messaging Implementation
> >> >> Project: http://qpid.apache.org
> >> >> Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> Regards,
> >>
> >> Rajith Attapattu
> >> Red Hat
> >> http://rajith.2rlabs.com/
> >>
> >> ---------------------------------------------------------------------
> >> Apache Qpid - AMQP Messaging Implementation
> >> Project: http://qpid.apache.org
> >> Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >>
> >>
> >
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jun 3, 2010 at 10:32 AM, Marnie McCormack
<ma...@googlemail.com> wrote:
> Hi Rajith,
> I'll let you decide - but could you assign it over to yourself if you are
> progressing ?
>
> As an aside, I don't think its practicable to be debating designs for such
> lengthy periods of time. Context switching is waste, and I think the elapsed
> time for design decisions on Apache represents a key challenge to productive
> development process.
I agree with you and I have been affected with the same in the past.
I was pretty swamped with an internal release, but will make every
effort to have something tomorrow so we could make good progress.
I appreciate the patience and the willingness to discuss by all
concerned parties.
There have been many features that were slapped in without much
discussion, so hopefully the time spent on this will bear fruit in a
better design that is agreeable to everybody concerned.
>
> Thanks,
> Marnie
> On Thu, Jun 3, 2010 at 3:08 PM, Rajith Attapattu <ra...@gmail.com> wrote:
>
>> Marine,
>>
>> I didn't see any commits related to this JIRA, so perhaps there are
>> related JIRA's to this which have commits under them?
>> Also there are no patches attached to this JIRA either.
>> If I am not mistaken, this JIRA was created mostly to discuss the
>> proposal. So since it hasn't reached a conclusion, I think it's best
>> to keep the JIRA open.
>>
>> I think it's probably useful to continue using this JIRA to thrash out
>> the proposal to ensure we capture all the history.
>> And then maybe when we agree on a concrete proposal we could create
>> JIRA's for specific areas that will have commits under them?
>> Is that fine with you ?
>>
>> Regards,
>>
>> Rajith
>>
>> On Thu, Jun 3, 2010 at 9:47 AM, Marnie McCormack
>> <ma...@googlemail.com> wrote:
>> > Hi Rajith,
>> >
>> > Would it be possible to separate out the remaing areas/items you'd like
>> to
>> > make a proposal on ?
>> >
>> > I noticed you suggested this approach on the JIRA (11th May) and ity'd be
>> > useful to be able to focus any frrther work on the specific items you'd
>> like
>> > to see. This JIRA is already a monster and the patches have been reviewed
>> > and committed.
>> >
>> > I'm sure Andrew will be responsive to you and any proposal.
>> >
>> > How does that sound ?
>> >
>> > Regards
>> > Marnie
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Jun 3, 2010 at 2:38 PM, Rajith Attapattu (JIRA) <
>> > qpid-dev@incubator.apache.org> wrote:
>> >
>> >>
>> >> [
>> >>
>> https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875107#action_12875107
>> ]
>> >>
>> >> Rajith Attapattu commented on QPID-2539:
>> >> ----------------------------------------
>> >>
>> >> Marnie,
>> >>
>> >> All though we discussed, I do not think we agreed on a concrete proposal
>> >> yet.
>> >> I believe there are still some open questions that didn't quite get
>> >> resolved.
>> >>
>> >> I am also working on a proposal which I am hoping to get out by
>> tomorrow.
>> >> So I'd appreciate if we keep this JIRA open until we get some sort of
>> >> agreement.
>> >>
>> >> Regards,
>> >>
>> >> Rajith
>> >>
>> >> > Update ACL file syntax to be clearer and add extra operations
>> >> > -------------------------------------------------------------
>> >> >
>> >> > Key: QPID-2539
>> >> > URL: https://issues.apache.org/jira/browse/QPID-2539
>> >> > Project: Qpid
>> >> > Issue Type: Sub-task
>> >> > Components: Java Broker
>> >> > Reporter: Andrew Kennedy
>> >> > Fix For: 0.7
>> >> >
>> >> > Attachments: acl.txt
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> This message is automatically generated by JIRA.
>> >> -
>> >> You can reply to this email to add a comment to the issue online.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> Apache Qpid - AMQP Messaging Implementation
>> >> Project: http://qpid.apache.org
>> >> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Rajith,
I'll let you decide - but could you assign it over to yourself if you are
progressing ?
As an aside, I don't think its practicable to be debating designs for such
lengthy periods of time. Context switching is waste, and I think the elapsed
time for design decisions on Apache represents a key challenge to productive
development process.
Thanks,
Marnie
On Thu, Jun 3, 2010 at 3:08 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> Marine,
>
> I didn't see any commits related to this JIRA, so perhaps there are
> related JIRA's to this which have commits under them?
> Also there are no patches attached to this JIRA either.
> If I am not mistaken, this JIRA was created mostly to discuss the
> proposal. So since it hasn't reached a conclusion, I think it's best
> to keep the JIRA open.
>
> I think it's probably useful to continue using this JIRA to thrash out
> the proposal to ensure we capture all the history.
> And then maybe when we agree on a concrete proposal we could create
> JIRA's for specific areas that will have commits under them?
> Is that fine with you ?
>
> Regards,
>
> Rajith
>
> On Thu, Jun 3, 2010 at 9:47 AM, Marnie McCormack
> <ma...@googlemail.com> wrote:
> > Hi Rajith,
> >
> > Would it be possible to separate out the remaing areas/items you'd like
> to
> > make a proposal on ?
> >
> > I noticed you suggested this approach on the JIRA (11th May) and ity'd be
> > useful to be able to focus any frrther work on the specific items you'd
> like
> > to see. This JIRA is already a monster and the patches have been reviewed
> > and committed.
> >
> > I'm sure Andrew will be responsive to you and any proposal.
> >
> > How does that sound ?
> >
> > Regards
> > Marnie
> >
> >
> >
> >
> >
> > On Thu, Jun 3, 2010 at 2:38 PM, Rajith Attapattu (JIRA) <
> > qpid-dev@incubator.apache.org> wrote:
> >
> >>
> >> [
> >>
> https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875107#action_12875107
> ]
> >>
> >> Rajith Attapattu commented on QPID-2539:
> >> ----------------------------------------
> >>
> >> Marnie,
> >>
> >> All though we discussed, I do not think we agreed on a concrete proposal
> >> yet.
> >> I believe there are still some open questions that didn't quite get
> >> resolved.
> >>
> >> I am also working on a proposal which I am hoping to get out by
> tomorrow.
> >> So I'd appreciate if we keep this JIRA open until we get some sort of
> >> agreement.
> >>
> >> Regards,
> >>
> >> Rajith
> >>
> >> > Update ACL file syntax to be clearer and add extra operations
> >> > -------------------------------------------------------------
> >> >
> >> > Key: QPID-2539
> >> > URL: https://issues.apache.org/jira/browse/QPID-2539
> >> > Project: Qpid
> >> > Issue Type: Sub-task
> >> > Components: Java Broker
> >> > Reporter: Andrew Kennedy
> >> > Fix For: 0.7
> >> >
> >> > Attachments: acl.txt
> >> >
> >> >
> >>
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> You can reply to this email to add a comment to the issue online.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Apache Qpid - AMQP Messaging Implementation
> >> Project: http://qpid.apache.org
> >> Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >>
> >>
> >
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Rajith Attapattu <ra...@gmail.com>.
Marine,
I didn't see any commits related to this JIRA, so perhaps there are
related JIRA's to this which have commits under them?
Also there are no patches attached to this JIRA either.
If I am not mistaken, this JIRA was created mostly to discuss the
proposal. So since it hasn't reached a conclusion, I think it's best
to keep the JIRA open.
I think it's probably useful to continue using this JIRA to thrash out
the proposal to ensure we capture all the history.
And then maybe when we agree on a concrete proposal we could create
JIRA's for specific areas that will have commits under them?
Is that fine with you ?
Regards,
Rajith
On Thu, Jun 3, 2010 at 9:47 AM, Marnie McCormack
<ma...@googlemail.com> wrote:
> Hi Rajith,
>
> Would it be possible to separate out the remaing areas/items you'd like to
> make a proposal on ?
>
> I noticed you suggested this approach on the JIRA (11th May) and ity'd be
> useful to be able to focus any frrther work on the specific items you'd like
> to see. This JIRA is already a monster and the patches have been reviewed
> and committed.
>
> I'm sure Andrew will be responsive to you and any proposal.
>
> How does that sound ?
>
> Regards
> Marnie
>
>
>
>
>
> On Thu, Jun 3, 2010 at 2:38 PM, Rajith Attapattu (JIRA) <
> qpid-dev@incubator.apache.org> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875107#action_12875107]
>>
>> Rajith Attapattu commented on QPID-2539:
>> ----------------------------------------
>>
>> Marnie,
>>
>> All though we discussed, I do not think we agreed on a concrete proposal
>> yet.
>> I believe there are still some open questions that didn't quite get
>> resolved.
>>
>> I am also working on a proposal which I am hoping to get out by tomorrow.
>> So I'd appreciate if we keep this JIRA open until we get some sort of
>> agreement.
>>
>> Regards,
>>
>> Rajith
>>
>> > Update ACL file syntax to be clearer and add extra operations
>> > -------------------------------------------------------------
>> >
>> > Key: QPID-2539
>> > URL: https://issues.apache.org/jira/browse/QPID-2539
>> > Project: Qpid
>> > Issue Type: Sub-task
>> > Components: Java Broker
>> > Reporter: Andrew Kennedy
>> > Fix For: 0.7
>> >
>> > Attachments: acl.txt
>> >
>> >
>>
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Rajith,
Would it be possible to separate out the remaing areas/items you'd like to
make a proposal on ?
I noticed you suggested this approach on the JIRA (11th May) and ity'd be
useful to be able to focus any frrther work on the specific items you'd like
to see. This JIRA is already a monster and the patches have been reviewed
and committed.
I'm sure Andrew will be responsive to you and any proposal.
How does that sound ?
Regards
Marnie
On Thu, Jun 3, 2010 at 2:38 PM, Rajith Attapattu (JIRA) <
qpid-dev@incubator.apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875107#action_12875107]
>
> Rajith Attapattu commented on QPID-2539:
> ----------------------------------------
>
> Marnie,
>
> All though we discussed, I do not think we agreed on a concrete proposal
> yet.
> I believe there are still some open questions that didn't quite get
> resolved.
>
> I am also working on a proposal which I am hoping to get out by tomorrow.
> So I'd appreciate if we keep this JIRA open until we get some sort of
> agreement.
>
> Regards,
>
> Rajith
>
> > Update ACL file syntax to be clearer and add extra operations
> > -------------------------------------------------------------
> >
> > Key: QPID-2539
> > URL: https://issues.apache.org/jira/browse/QPID-2539
> > Project: Qpid
> > Issue Type: Sub-task
> > Components: Java Broker
> > Reporter: Andrew Kennedy
> > Fix For: 0.7
> >
> > Attachments: acl.txt
> >
> >
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Andrew Kennedy <an...@gmail.com>.
On 14 May 2010 16:19, Rajith Attapattu <ra...@gmail.com> wrote:
> I am bit swamped today, so apologies for not participating in the
> discussion today.
> Andrew I will have a look at the text you put together and try to
> reply by monday.
> Do you mind if I put that in the wiki and then mark my comments
> underneath in a different color?
>
> If need be we could potentially split this JIRA into more focused
> areas to avoid lengthy discussions on the format that maybe difficult
> to follow as time goes on.
> I also have a set of my own proposals, however I may not have time to
> put them together until mid next week.
yes, thx.
thought the JIRA was an adequate place for discussion, at least in
terms of the file format/capabilities. i'm also still to add more
details on the auth/group additions, though. as far as i knoew, things
like making the security plugins osgi bundles was already a work in
progress, so finish that was a necessary prerequisite.
i will also be posting the first set of patches for these updates,
since they include changes to the Plugin mechanism that I would like
opinions on. As I say, I don't intend this to be final, just a working
first cut.
cheers,
adk.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Rajith Attapattu <ra...@gmail.com>.
I am bit swamped today, so apologies for not participating in the
discussion today.
Andrew I will have a look at the text you put together and try to
reply by monday.
Do you mind if I put that in the wiki and then mark my comments
underneath in a different color?
If need be we could potentially split this JIRA into more focused
areas to avoid lengthy discussions on the format that maybe difficult
to follow as time goes on.
I also have a set of my own proposals, however I may not have time to
put them together until mid next week.
Regards,
Rajith
On Fri, May 14, 2010 at 11:11 AM, Carl Trieloff (JIRA)
<qp...@incubator.apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867521#action_12867521 ]
>
> Carl Trieloff commented on QPID-2539:
> -------------------------------------
>
> PROP_MAXQUEUESIZE, PROP_MAXQUEUECOUNT --- queue depth on queue creation via ACL. used by selfservice users who want users to be able to declare a queue but only get a pre-defined or less queue size.
>
> package and class refer to QMF, so you can scope ACL to any QMF method.
>
> What is OWNER used for in the Java broker?
>
> Carl.
>
>> Update ACL file syntax to be clearer and add extra operations
>> -------------------------------------------------------------
>>
>> Key: QPID-2539
>> URL: https://issues.apache.org/jira/browse/QPID-2539
>> Project: Qpid
>> Issue Type: Sub-task
>> Components: Java Broker
>> Reporter: Andrew Kennedy
>> Fix For: 0.7
>>
>> Attachments: acl.txt
>>
>>
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/19/2010 12:30 PM, Andrew Kennedy wrote:
> On 19 May 2010 17:22, Carl Trieloff<cc...@redhat.com> wrote:
>
>>
>> I've had a brief read, it seem seems the point I was trying to make has
>> been entirely miss-understood.
>>
>> How about some IRC, or a call if you can do that and the reflect back to the
>> list.
>>
>> Carl.
>>
> Carl,
>
> I'm off home just now, but maybe if we have a chat tomorrow when
> you're free? I would like to get this cleared up, because it seems
> like a simple little thing and it shouldn't hold up progress. What I'd
> like to get agreed on is a mechanism for permissioning the management
> entry-points of the broker.
>
> I don't have IRC access, so can you reply to this with a number and
> time I can get you on, and maybe we can come up with a solution to
> post to the list tomorrow?
>
> Cheers,
> Andrew.
>
I've sent phone number privately.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Andrew Kennedy <an...@gmail.com>.
On 19 May 2010 17:22, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> I've had a brief read, it seem seems the point I was trying to make has
> been entirely miss-understood.
>
> How about some IRC, or a call if you can do that and the reflect back to the
> list.
>
> Carl.
Carl,
I'm off home just now, but maybe if we have a chat tomorrow when
you're free? I would like to get this cleared up, because it seems
like a simple little thing and it shouldn't hold up progress. What I'd
like to get agreed on is a mechanism for permissioning the management
entry-points of the broker.
I don't have IRC access, so can you reply to this with a number and
time I can get you on, and maybe we can come up with a solution to
post to the list tomorrow?
Cheers,
Andrew.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Andrew Kennedy <an...@gmail.com>.
On 19 May 2010 17:22, Carl Trieloff <cc...@redhat.com> wrote:
> I've had a brief read, it seem seems the point I was trying to make has
> been entirely miss-understood.
>
> How about some IRC, or a call if you can do that and the reflect back to the
> list.
>
> Carl.
Hi.
I talked with carl, and I think we are basically on the same page,
apart from some minor confusion over naming and definitions which I
think I now understand better. Basically, the 'Conclusions' section of
the document I posted earlier describes the way ACLs on management
functions will work, however I have added a post-script with some more
detail, including an explanation of what exactly a 'mangement
function' is. Additionally, I have updated the original proposal to
reflect the changes to the object type and operation combinations. I
am in the process of getting the wiki pages updated, but in the
meantime I have attached three text files to QPID-2476 and the
post-script and part of the conclusion are reproduced below:
{noformat}
ACL ALLOW kitten EXECUTE METHOD component="log" name="reload*"
ACL ALLOW kitten UPDATE METHOD component="log"
ACL ALLOW robot ACCESS METHOD component="log"
ACL ALLOW robot EXECUTE METHOD component="acl" name="reload*"
ACL DENY robot EXECUTE METHOD component="config" name="reload*"
ACL ALLOW robot EXECUTE METHOD component="config"
{noformat}
h2. Post Scriptum
The following points should clarify some of the proposed features,
however the syntax as described in the [#Conclusion] is intended to
represent the preferred usage.
In the C++ broker there exists a feature wherby plugins, uniquely
identified by a schema package and a class name, can have ACLs applied
to them. This will also become available in the Java broker, and would
be permissioned using the _OBJECT_ object type. This allows objects
that are external to the broker to be controlled. For the Java broker
it is intended that the main class for a plugin would check with the
security manager using the Java package and class names as properties,
as below.
{noformat}
ACL ALLOW kittens ACCESS OBJECT package="com.example.plugin" class="Example"
{noformat}
When management functions are being permissioned, a symbolic name for
a logical grouping of related methods, properties, attributes and
operations is used to identify what is being controlled. This is
identified using the _component_ property in the examples above. These
groupings will map onto JMX managed objects or MBeans, QMF management
schemas, or some other form of mangement object. It is intended that a
particular broker implementation handles these mappings internally and
ignores mappings that do not exist, such as logging management on the
C++ broker currently. It is also possible to offer finer grained
control by specifying the _name_ property for the ACL entry, thus
restricting the scope to a single method or property. It _may_ also be
possible to specify other properties that have meaning for a paricular
broker implementation, thus maintaining backward compatibility. The
list of possible property names should be fixed as part of the
definition of the ACL file format.
Cheers,
Andrew.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by Carl Trieloff <cc...@redhat.com>.
I've had a brief read, it seem seems the point I was trying to make has
been entirely miss-understood.
How about some IRC, or a call if you can do that and the reflect back to
the list.
Carl.
On 05/19/2010 11:59 AM, Andrew Kennedy wrote:
> On 18 May 2010 14:52, Rajith Attapattu<ra...@gmail.com> wrote:
>
>> Andrew, I have added your proposal and the text you pasted here in
>> https://cwiki.apache.org/confluence/display/qpid/andrew+acl+proposal
>>
>> This page is linked off,
>> https://cwiki.apache.org/confluence/display/qpid/ACL+Design
>> And the above is linked off the developer pages.
>>
>> I will get out my proposal a bit later in the week.
>>
> Thanks.
>
> For completeness, I have tried to put together another page covering
> the recent discussion on the 'METHOD' object and management
> operations, the text of which is attached below. Rajith, could you
> stick it in another wiki page, please? I think this is a useful
> compromise, although there may be some further work required to
> straighten out the QMF and JMX bindings anyway...
>
> h1. Method Redux
>
> _"Though this be madness, yet there is method in't."_
> *Polonius, Hamlet Act 2, scene 2*
>
> h2. Introduction
>
> The main point of contention in the ACL debate seems to centre around
> the mechanism used to permission non AMQP entities, the current
> _METHOD_ method is felt to be unsuitable. This document proposes an
> update to this syntax and describes exactly how it should be
> interpreted across brokers.
>
> h2. Access Control
>
> The things that are being controlled or permissioned by entries in the
> access control list are objects that form part of the Qpid broker.
> These entities could reasonably be said to be _children_ of the
> broker, although I don't feel that a tree-type structure is either
> helpful or necessary here, since there is no parallel in the Qpid or
> AMQP internals. A flat _object type_ space has therefore been assumed,
> continuing current behavior. These types of object have until now
> simply represented the major types of object that exist and are
> manipulable inside a broker. The only addition is that of the broker
> itself, since there are some operations and actions that can only
> realistically be said to be performed globally. This is the rationale
> behind such proposed ACL entries as:
>
> {noformat}
> ACL ALLOW robot ACCESS LOG
> ACL DENY robot UPDATE CONFIG
> ACL DENY kitten UPDATE USERS
> ACL ALLOW kitten ADMIN LOG
> {noformat}
>
> The _LOG_, _CONFIG_ and _USERS_ object types here represent subsystems
> or components or simply collections of management methods that perform
> a similar set of tasks. They are *not* actual broker objects, although
> (see later) they may be QMF classes, with their own management schema
> and package.
>
> A different approach to access control for these management methods
> relies on the _BROKER_ object type being used for permissioning,
> giving rise to ACL entries as follows:
>
> {noformat}
> ACL DENY robot ACCESS BROKER
> ACL DENY kitten UPDATE BROKER subsystem=logging
> ACL ALLOW kitten ACCESS BROKER method=get*
> ACL ALLOW kitten ACCESS BROKER method=invoke*
> ACL ALLOW kitten MANAGE BROKER subsystem=users
> {noformat}
>
> This _BROKER_ object type represents the entire runtime entity, and is
> in fact represented in the QMF management schema, with properties,
> statistics and methods available. This is not meant to indicate a
> preference for QMF as a final reference point, it should be noted,
> rather this is illustrative of the sorts of entities an access control
> object type could map to.
>
> {noformat}
> <class name="Broker">
> <property name="name" />
> <property name="systemRef" />
> <property name="port" />
> </class>
> {noformat}
>
> h3. Existing Syntax
>
> The previous ACL entries would all be permissioned using the _METHOD_
> object type in the current C++ broker, assuming a logical extension of
> the existing syntax. The problem with this syntax is that it is very
> closely coupled to the management framework, QMF. Also, the
> granularity of the controls falls awkwardly between extremes, and
> requires too much specificity to enumerate all methods dealing with a
> particular area of interest when controlling that type of access, and
> not distinguishing between *getName* methods on various different
> managed objects. This makes it impossible to correctly permission
> access to multiple objects with similarly named methods. Also, since
> JMX provides access to properties using a method call, a permission
> for that method would need to be created to allow _READ_ access to a
> property, which blurs the distiction between methods and properties.
>
> h3. Mechanism versus Meaning
>
> Since the current C++ implementation is based exclusively on QMF, only
> features supported and used by QMF are available. It is preferable to
> have a mechanism-agnostic access control specification, since QMF and
> JMX will not be the only management entry-points for ever, with SNMP
> and other industry standards available as well as future JEE
> development. Also, it should be possible to permission access in a
> manner that does not depend on the version of the QMF schema or API,
> depending only on the existence or not of particular manageable
> objects within the broker. This means that when a new method or
> attribute is added at an API change, or a method name is changed,
> existing ACLS will have the same meaning as before. This semantic
> preservation is the aspect of the ACLs that is most important.
>
> The existing object types all relate to the Qpid broker objects, and
> the best way to move forward is to maintain that relationship, and
> ensure that all operations have the correct meaning and are controlled
> correctly in the broker, no matter how they are accessed. This means
> that an _ACCESS QUEUE_ ACL entry would entail granting permission to
> view the properties of a queue via the QMF console, via a JMX console
> utility or the JMX API and by interrogating the queue over JMS or
> through the C++ AMQP client.
>
> h3. Operational Constraints
>
> The _ACCESS_ operation is assumed here to map to some kind of
> read-only access. Typically in a software management system the
> following three types of operation are available:
>
> * *Read* - Access the contents of an attribute, statistic or property.
> * *Write* - Set the contents of an attribute or property.
> * *Execute* - Call a method or take an action or operation.
>
> It is proposed that the existing operations are maintained, along with
> the mappings to object types they are allowed to manipulate (as
> described in a previous text) and the three types described above are
> mapped as follows:
>
> * _ACCESS_ - *Read*
> * _UPDATE_ - *Write*
> * _EXECUTE_ - *Execute*
>
> _ACCESS_ continues to describe simple, read-only property or attribute
> access, mapping nicely a JMX intent of INFO or a *get* type of
> operation. _UPDATE_ would be used for read-write access to properties,
> when the operation carried out is a simple change of value with no
> side effects. The new _EXECUTE_ operation replaces the contentious
> _ADMIN_ or _MANAGE_ described previously, and more accurately
> describes the execution or invocation of an administrative action or
> operation with a particular effect on the broker.
>
> h3. Brokerage
>
> The _BROKER_ object type is to be used to control access to any new
> set of features. For example, if it is desired to add an ACL entry
> that will allow the _robots_ group to read and write properties on the
> *Acl* QMF managed object, and additionally to execute all methods that
> are present, this could be done as follows:
>
> {noformat}
> ACL ALLOW robots ACCESS BROKER package="org.apache.qpid.acl"
> ACL ALLOW robots UPDATE BROKER package="org.apache.qpid.acl"
> ACL ALLOW robots EXECUTE BROKER package="org.apache.qpid.acl"
> {noformat}
>
> If a logging subsystem was added, with the QMF management schema
> package defined as *org.apache.qpid.log* and methods such as
> *setLoggingLevel*, *getAvailableLoggingLevels*, *reloadLogFile*,
> *rollLogFile* are defined, along with properties like *currentLevel*
> and *lastLogEntryTime* then it could be permissioned this way:
>
> {noformat}
> ACL ALLOW robots ACCESS BROKER package="org.apache.qpid.log"
> ACL ALLOW robots UPDATE BROKER package="org.apache.qpid.log"
> ACL ALLOW kitten EXECUTE BROKER package="org.apache.qpid.log"
> method="rollLogFile"
> ACL ALLOW robots EXECUTE BROKER package="org.apache.qpid.log"
> method="reloadLogFile"
> ACL DENY robots EXECUTE BROKER package="org.apache.qpid.log"
> {noformat}
>
> In this example, the _robots_ group can only execute *reloadLogFile*
> while _kitten_ (a member) can also execute *rollLogFile*, and the
> group has read/write access to all properties and statistics. It
> should be obvious that there is scope for adding arbitrary new
> packages and then permissioning them. Also, if the contents of the
> packages are well defined and they are suitably finely grained then it
> will mostly suffice to permission at the package level for all
> operations and properties. This gives freedom to update APIs and add
> new methods without making ACL files obsolete or causing security
> issues, since the *meaning* of the ACL entries should be unchanged.
>
> Care will need to be taken with, for example, JMX *invoke* method,
> which offers a level of indirection that could enable bypassing access
> checks. This is currently handled at a common JMX entry point, and
> should suffice at present.
>
> h3. Syntactic Sugar
>
> In an attempt to divorce the ACL syntax from the mechanism further, it
> could also be possible to remove references to the package and use a
> different naming scheme, which would have a mapping to QMF, JMX
> managed objects and any future management information repository. This
> could work as follows, with *users* mapping to the JMX
> *UserManagement* MBean and a QMF *org.apache.qpid.users* package with
> a *Users* class. The change to the ACL syntax is trivial.
> Additionally, changing all properties to simply _name_ would
> standardise the syntax further, with only a small loss of readability.
>
> {noformat}
> ACL ALLOW kitten EXECUTE BROKER component="users" name="*"
> ACL ALLOW kitten UPDATE BROKER component="users" name="fileName"
> {noformat}
>
> It is possible that another object could be chosen instead of
> _BROKER_, such as _METHOD_ (however this gives the issue of changing
> the meaning of existing files) but this would not change the
> discussion presented above. The only issue might be that it is
> cumbersome to add a permission granting access to all management
> methods, properties and statistics, both read and write, at the same
> time. Even though _UPDATE_ will usually include _ACCESS_ permissions,
> two lines are needed (for _EXECUTE_ separately) unless it is
> satisfactory for _EXECUTE_ to include _UPDATE_ (and hence _ACCESS_)
> rights.
>
> {noformat}
> ACL DENY robot EXECUTE METHOD component="config" name="reload*"
> ACL ALLOW kitten ACCESS METHOD component="config" name="*"
> {noformat}
>
> It could be pointed out that _ACCESS METHOD_ ought more correctly to
> read _ACCESS PROPERTY_ and similarly for _UPDATE_, however it is felt
> that the number of object types should be kept to a minimum, which is
> the purpose of this proposal.
>
> h2. Conclusion
>
> The ACL changes described above are fairly simple, but should provide
> a sensible and easily extensible syntax that will allow both the Java
> and C++ brokers to provide fine grained access control for custom
> components that are specific to each implementation without
> compromising cross- platform file compatibility. The actual access and
> management mechanisms for the brokers do not impact the ACL syntax,
> which remains agnostic, and also maintains its meaning through API
> upgrades and extensions without compromising platform security.
>
> There are several options for ACL file syntax describing access to
> methods controlling a (for example) logging mechanism, which are
> summarised below:
>
> * Extra object type created for each set of management methods, with
> unique per-object set of properties. This is the least extensible
> mechanism.
>
> {noformat}
> ACL ALLOW kitten EXECUTE LOG
> {noformat}
>
> * Specify all method names to be permissioned as in the current C++
> broker implementation, using _METHOD_ as the object type. This does
> not allow property access to be permissioned or prevent name clashes
> in different managed object classes.
>
> {noformat}
> ACL ALLOW kitten UPDATE METHOD name="methodNameOne"
> ACL ALLOW kitten UPDATE METHOD name="methodNameTwo"
> {noformat}
>
> * Use _BROKER_ or _METHOD_ object type and specify the component or
> subsystem by an arbitrary name, with the option to specify down to
> individual methods by adding a wildcarded name pattern. Using _METHOD_
> in this way is close to the current C++ syntax. Alternatively, the QMF
> package name could be used to identify the component. Different
> operations are used to describe access to properties or attributes.
>
> {noformat}
> ACL ALLOW kitten EXECUTE BROKER subsystem=logging
> ACL ALLOW kitten EXECUTE BROKER package="org.apache.qpid.log"
> {noformat}
>
> {noformat}
> ACL ALLOW kitten EXECUTE METHOD component="log" name="reload*"
> ACL ALLOW kitten UPDATE METHOD component="log"
> ACL ALLOW robot ACCESS METHOD component="log"
> ACL ALLOW robot EXECUTE METHOD component="acl" name="reload*"
> ACL DENY robot EXECUTE METHOD component="config" name="reload*"
> ACL ALLOW robot EXECUTE METHOD component="config"
> {noformat}
>
> The last described syntax is close to a preferred option, and
> incorporates features from recent *dev.qpid.apache.org* discussion,
> although any updates or suggestions are welcome.
>
> (*Note* this has the interesting/useful feature/bug of falling back to
> C++ broker syntax if the _component_ property is omitted. This would
> be legal in the Java broker, just not recommended due to the name
> clashes.)
>
> Andrew D Kennedy, _andrew.international@gmail.com_, 2010-05-19
>
> adk
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Andrew Kennedy <an...@gmail.com>.
On 18 May 2010 14:52, Rajith Attapattu <ra...@gmail.com> wrote:
>
> Andrew, I have added your proposal and the text you pasted here in
> https://cwiki.apache.org/confluence/display/qpid/andrew+acl+proposal
>
> This page is linked off,
> https://cwiki.apache.org/confluence/display/qpid/ACL+Design
> And the above is linked off the developer pages.
>
> I will get out my proposal a bit later in the week.
Thanks.
For completeness, I have tried to put together another page covering
the recent discussion on the 'METHOD' object and management
operations, the text of which is attached below. Rajith, could you
stick it in another wiki page, please? I think this is a useful
compromise, although there may be some further work required to
straighten out the QMF and JMX bindings anyway...
h1. Method Redux
_"Though this be madness, yet there is method in't."_
*Polonius, Hamlet Act 2, scene 2*
h2. Introduction
The main point of contention in the ACL debate seems to centre around
the mechanism used to permission non AMQP entities, the current
_METHOD_ method is felt to be unsuitable. This document proposes an
update to this syntax and describes exactly how it should be
interpreted across brokers.
h2. Access Control
The things that are being controlled or permissioned by entries in the
access control list are objects that form part of the Qpid broker.
These entities could reasonably be said to be _children_ of the
broker, although I don't feel that a tree-type structure is either
helpful or necessary here, since there is no parallel in the Qpid or
AMQP internals. A flat _object type_ space has therefore been assumed,
continuing current behavior. These types of object have until now
simply represented the major types of object that exist and are
manipulable inside a broker. The only addition is that of the broker
itself, since there are some operations and actions that can only
realistically be said to be performed globally. This is the rationale
behind such proposed ACL entries as:
{noformat}
ACL ALLOW robot ACCESS LOG
ACL DENY robot UPDATE CONFIG
ACL DENY kitten UPDATE USERS
ACL ALLOW kitten ADMIN LOG
{noformat}
The _LOG_, _CONFIG_ and _USERS_ object types here represent subsystems
or components or simply collections of management methods that perform
a similar set of tasks. They are *not* actual broker objects, although
(see later) they may be QMF classes, with their own management schema
and package.
A different approach to access control for these management methods
relies on the _BROKER_ object type being used for permissioning,
giving rise to ACL entries as follows:
{noformat}
ACL DENY robot ACCESS BROKER
ACL DENY kitten UPDATE BROKER subsystem=logging
ACL ALLOW kitten ACCESS BROKER method=get*
ACL ALLOW kitten ACCESS BROKER method=invoke*
ACL ALLOW kitten MANAGE BROKER subsystem=users
{noformat}
This _BROKER_ object type represents the entire runtime entity, and is
in fact represented in the QMF management schema, with properties,
statistics and methods available. This is not meant to indicate a
preference for QMF as a final reference point, it should be noted,
rather this is illustrative of the sorts of entities an access control
object type could map to.
{noformat}
<class name="Broker">
<property name="name" />
<property name="systemRef" />
<property name="port" />
</class>
{noformat}
h3. Existing Syntax
The previous ACL entries would all be permissioned using the _METHOD_
object type in the current C++ broker, assuming a logical extension of
the existing syntax. The problem with this syntax is that it is very
closely coupled to the management framework, QMF. Also, the
granularity of the controls falls awkwardly between extremes, and
requires too much specificity to enumerate all methods dealing with a
particular area of interest when controlling that type of access, and
not distinguishing between *getName* methods on various different
managed objects. This makes it impossible to correctly permission
access to multiple objects with similarly named methods. Also, since
JMX provides access to properties using a method call, a permission
for that method would need to be created to allow _READ_ access to a
property, which blurs the distiction between methods and properties.
h3. Mechanism versus Meaning
Since the current C++ implementation is based exclusively on QMF, only
features supported and used by QMF are available. It is preferable to
have a mechanism-agnostic access control specification, since QMF and
JMX will not be the only management entry-points for ever, with SNMP
and other industry standards available as well as future JEE
development. Also, it should be possible to permission access in a
manner that does not depend on the version of the QMF schema or API,
depending only on the existence or not of particular manageable
objects within the broker. This means that when a new method or
attribute is added at an API change, or a method name is changed,
existing ACLS will have the same meaning as before. This semantic
preservation is the aspect of the ACLs that is most important.
The existing object types all relate to the Qpid broker objects, and
the best way to move forward is to maintain that relationship, and
ensure that all operations have the correct meaning and are controlled
correctly in the broker, no matter how they are accessed. This means
that an _ACCESS QUEUE_ ACL entry would entail granting permission to
view the properties of a queue via the QMF console, via a JMX console
utility or the JMX API and by interrogating the queue over JMS or
through the C++ AMQP client.
h3. Operational Constraints
The _ACCESS_ operation is assumed here to map to some kind of
read-only access. Typically in a software management system the
following three types of operation are available:
* *Read* - Access the contents of an attribute, statistic or property.
* *Write* - Set the contents of an attribute or property.
* *Execute* - Call a method or take an action or operation.
It is proposed that the existing operations are maintained, along with
the mappings to object types they are allowed to manipulate (as
described in a previous text) and the three types described above are
mapped as follows:
* _ACCESS_ - *Read*
* _UPDATE_ - *Write*
* _EXECUTE_ - *Execute*
_ACCESS_ continues to describe simple, read-only property or attribute
access, mapping nicely a JMX intent of INFO or a *get* type of
operation. _UPDATE_ would be used for read-write access to properties,
when the operation carried out is a simple change of value with no
side effects. The new _EXECUTE_ operation replaces the contentious
_ADMIN_ or _MANAGE_ described previously, and more accurately
describes the execution or invocation of an administrative action or
operation with a particular effect on the broker.
h3. Brokerage
The _BROKER_ object type is to be used to control access to any new
set of features. For example, if it is desired to add an ACL entry
that will allow the _robots_ group to read and write properties on the
*Acl* QMF managed object, and additionally to execute all methods that
are present, this could be done as follows:
{noformat}
ACL ALLOW robots ACCESS BROKER package="org.apache.qpid.acl"
ACL ALLOW robots UPDATE BROKER package="org.apache.qpid.acl"
ACL ALLOW robots EXECUTE BROKER package="org.apache.qpid.acl"
{noformat}
If a logging subsystem was added, with the QMF management schema
package defined as *org.apache.qpid.log* and methods such as
*setLoggingLevel*, *getAvailableLoggingLevels*, *reloadLogFile*,
*rollLogFile* are defined, along with properties like *currentLevel*
and *lastLogEntryTime* then it could be permissioned this way:
{noformat}
ACL ALLOW robots ACCESS BROKER package="org.apache.qpid.log"
ACL ALLOW robots UPDATE BROKER package="org.apache.qpid.log"
ACL ALLOW kitten EXECUTE BROKER package="org.apache.qpid.log"
method="rollLogFile"
ACL ALLOW robots EXECUTE BROKER package="org.apache.qpid.log"
method="reloadLogFile"
ACL DENY robots EXECUTE BROKER package="org.apache.qpid.log"
{noformat}
In this example, the _robots_ group can only execute *reloadLogFile*
while _kitten_ (a member) can also execute *rollLogFile*, and the
group has read/write access to all properties and statistics. It
should be obvious that there is scope for adding arbitrary new
packages and then permissioning them. Also, if the contents of the
packages are well defined and they are suitably finely grained then it
will mostly suffice to permission at the package level for all
operations and properties. This gives freedom to update APIs and add
new methods without making ACL files obsolete or causing security
issues, since the *meaning* of the ACL entries should be unchanged.
Care will need to be taken with, for example, JMX *invoke* method,
which offers a level of indirection that could enable bypassing access
checks. This is currently handled at a common JMX entry point, and
should suffice at present.
h3. Syntactic Sugar
In an attempt to divorce the ACL syntax from the mechanism further, it
could also be possible to remove references to the package and use a
different naming scheme, which would have a mapping to QMF, JMX
managed objects and any future management information repository. This
could work as follows, with *users* mapping to the JMX
*UserManagement* MBean and a QMF *org.apache.qpid.users* package with
a *Users* class. The change to the ACL syntax is trivial.
Additionally, changing all properties to simply _name_ would
standardise the syntax further, with only a small loss of readability.
{noformat}
ACL ALLOW kitten EXECUTE BROKER component="users" name="*"
ACL ALLOW kitten UPDATE BROKER component="users" name="fileName"
{noformat}
It is possible that another object could be chosen instead of
_BROKER_, such as _METHOD_ (however this gives the issue of changing
the meaning of existing files) but this would not change the
discussion presented above. The only issue might be that it is
cumbersome to add a permission granting access to all management
methods, properties and statistics, both read and write, at the same
time. Even though _UPDATE_ will usually include _ACCESS_ permissions,
two lines are needed (for _EXECUTE_ separately) unless it is
satisfactory for _EXECUTE_ to include _UPDATE_ (and hence _ACCESS_)
rights.
{noformat}
ACL DENY robot EXECUTE METHOD component="config" name="reload*"
ACL ALLOW kitten ACCESS METHOD component="config" name="*"
{noformat}
It could be pointed out that _ACCESS METHOD_ ought more correctly to
read _ACCESS PROPERTY_ and similarly for _UPDATE_, however it is felt
that the number of object types should be kept to a minimum, which is
the purpose of this proposal.
h2. Conclusion
The ACL changes described above are fairly simple, but should provide
a sensible and easily extensible syntax that will allow both the Java
and C++ brokers to provide fine grained access control for custom
components that are specific to each implementation without
compromising cross- platform file compatibility. The actual access and
management mechanisms for the brokers do not impact the ACL syntax,
which remains agnostic, and also maintains its meaning through API
upgrades and extensions without compromising platform security.
There are several options for ACL file syntax describing access to
methods controlling a (for example) logging mechanism, which are
summarised below:
* Extra object type created for each set of management methods, with
unique per-object set of properties. This is the least extensible
mechanism.
{noformat}
ACL ALLOW kitten EXECUTE LOG
{noformat}
* Specify all method names to be permissioned as in the current C++
broker implementation, using _METHOD_ as the object type. This does
not allow property access to be permissioned or prevent name clashes
in different managed object classes.
{noformat}
ACL ALLOW kitten UPDATE METHOD name="methodNameOne"
ACL ALLOW kitten UPDATE METHOD name="methodNameTwo"
{noformat}
* Use _BROKER_ or _METHOD_ object type and specify the component or
subsystem by an arbitrary name, with the option to specify down to
individual methods by adding a wildcarded name pattern. Using _METHOD_
in this way is close to the current C++ syntax. Alternatively, the QMF
package name could be used to identify the component. Different
operations are used to describe access to properties or attributes.
{noformat}
ACL ALLOW kitten EXECUTE BROKER subsystem=logging
ACL ALLOW kitten EXECUTE BROKER package="org.apache.qpid.log"
{noformat}
{noformat}
ACL ALLOW kitten EXECUTE METHOD component="log" name="reload*"
ACL ALLOW kitten UPDATE METHOD component="log"
ACL ALLOW robot ACCESS METHOD component="log"
ACL ALLOW robot EXECUTE METHOD component="acl" name="reload*"
ACL DENY robot EXECUTE METHOD component="config" name="reload*"
ACL ALLOW robot EXECUTE METHOD component="config"
{noformat}
The last described syntax is close to a preferred option, and
incorporates features from recent *dev.qpid.apache.org* discussion,
although any updates or suggestions are welcome.
(*Note* this has the interesting/useful feature/bug of falling back to
C++ broker syntax if the _component_ property is omitted. This would
be legal in the Java broker, just not recommended due to the name
clashes.)
Andrew D Kennedy, _andrew.international@gmail.com_, 2010-05-19
adk
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, May 18, 2010 at 7:13 AM, Andrew Kennedy
<an...@gmail.com> wrote:
> On 17 May 2010 17:43, Carl Trieloff <cc...@redhat.com> wrote:
>>
>> part I am confused about in the thread is the following: Why introduce
>> additional opperations to the ACL file format when they can already
>> be covered with what is already in the format?
>>
>> I can see why we need to add (vhost, subnetmask) -- no argument there.
>> owner - I'm not 100% sure on but seems reasonable
>>
>> I don't see why any of the other additions are needed (config, admin,
>> connect,..). I'm not saying we should not cover x case, I just don't see
>> yet why it is not covered with what is already there.
>>
>> If we can't cover with what is there, adding is fine, but I'm not convinced
>> yet that they are needed to cover any of the cases put forward so far in
>> the JIRA.
>
> OK, the IP whitelisting/firewalling is a separate issue, but here is my
> summary of the proposal I have for new ACL methods. I'd appreciate
> comments. Also, Rajith, could you append the following text to the wiki
> page you're creating, since I don't have access, please?
>
Andrew, I have added your proposal and the text you pasted here in
https://cwiki.apache.org/confluence/display/qpid/andrew+acl+proposal
This page is linked off,
https://cwiki.apache.org/confluence/display/qpid/ACL+Design
And the above is linked off the developer pages.
I will get out my proposal a bit later in the week.
Rajith
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/18/2010 07:13 AM, Andrew Kennedy wrote:
> On 17 May 2010 17:43, Carl Trieloff<cc...@redhat.com> wrote:
>
>> part I am confused about in the thread is the following: Why introduce
>> additional opperations to the ACL file format when they can already
>> be covered with what is already in the format?
>>
>> I can see why we need to add (vhost, subnetmask) -- no argument there.
>> owner - I'm not 100% sure on but seems reasonable
>>
>> I don't see why any of the other additions are needed (config, admin,
>> connect,..). I'm not saying we should not cover x case, I just don't see
>> yet why it is not covered with what is already there.
>>
>> If we can't cover with what is there, adding is fine, but I'm not convinced
>> yet that they are needed to cover any of the cases put forward so far in
>> the JIRA.
>>
> OK, the IP whitelisting/firewalling is a separate issue, but here is my
> summary of the proposal I have for new ACL methods. I'd appreciate
> comments. Also, Rajith, could you append the following text to the wiki
> page you're creating, since I don't have access, please?
>
> == METHOD considered harmful ==
>
> A lot of the object types and operations used in the ACL file are shared
> between the Java and C++ brokers and are non-contentious, since they
> represent actual objects that exist in AMQP - broker, queue, exchange
> and so forth. What appears to be at issue is how to permission extra
> funtionality in the broker, such as administration of user accounts or
> logging levels The C++ broker's 'METHOD' object is one mechanism, and
> results in ACL lines that specify a single method or set of methods that
> can be executed, and does not convey whether these are reading, writing
> or have other side effects on the broker. An example is shoen below:
>
> ACL ALLOW adk UPDATE METHOD name=getLoggingLevel
> ACL ALLOW adk UPDATE METHOD name=setLoggingLevel
> ACL ALLOW adk UPDATE METHOD name=reloadLoggingConfig
>
> This seems to be at the wrong level of abstraction. Looking at this
> in a general fashion, there are three things we wish to do to objects:
> get a property, set a property and execute an operation. These can be
> mapped to READ, WRITE, EXECUTE or GET, SET, INVOKE, ACCESS, UPDATE,
> ADMIN, and so on as operations. The next step would be to decide what
> the object type is that is being manipulated. I would be happy for this
> to be one of the existing AMQP objects, including BROKER, since this
> follows the existing pattern of permissions. Another point to note is
> that existing mechanisms such as JMX already have the conceptual split
> into these three types of action.
>
> If we abandon the METHOD object in favour of existing object types, we
> still need to be able to permission such items as users and logging, and
> I propose these are made part of the broker object, with the possibility
> of adding other, vendor-specific extensions too. This would result in ACL
> lines as shown below, which would grant permission to view attributes
> of the logging subsystem, update those attributes and execute other
> administrative actions. Finally, if there is a management schema change
> and the names of methods used change, or new methods and attributes are
> added, the ACL file does not have to be changed, since the permissions
> relate to subsystems or extensions.
>
> ACL ALLOW adk ACCESS BROKER extension=logging
> ACL ALLOW adk UPDATE BROKER extension=logging
> ACL ALLOW adk ADMIN BROKER extension=logging
> or
> ACL ALLOW adk ADMIN BROKER subsystem=acl
>
> If we want to create an ACL file format that is usable across AMQP
> brokers, then the use of 'extension=<name>' or 'subsystem=<name>' with
> a set of pre-defined names, say 'logging', 'users', 'configuration',
> and a naming convention to prevent clashes, such as 'x-<vendor>-*'
> for vendor specific implementations or just 'x-*' for experimental
> extensions/subsystems seems appropriate.
>
>
Some of your reasoning is good, some I don't agree with.
if we use
READ, WRITE, EXECUTE
then
METHOD today == EXECUTE
or
GET, SET, INVOKE, ACCESS, UPDATE
then
METHOD today == INVOKE
that seems like a reasonable rename.
Being able to apply ACL at a single method level is required. If you want to
apply ACL to section of the ACL schema, then you can do that. For example for
broker, queue, xyz, or foobar. The schema tag allows you to do that.
thus schema in the C++ broker today seems to be equivalent to the extension/ subsystem
command but cleaner as it maps directly to any QMF schema object we decide to create.
However, the following command makes NO sense
ACL ALLOW adk ADMIN BROKER subsystem=acl
First ADMIN is not a command, should not be. it could be a group with permissions
Then BROKER and subsystem=acl make no sense together / have no idea how to implement this, it is assuming
acl is sub broker, which it is not. I understand what you are trying to do, but the relationships are not
right.
If you look at the schema (broker& acl are separate objects), it would be written like this.
group ADMIN adk
acl allow ADMIN all schemapackage=org.apache.qpid.acl
note that broker is actually
<schema package="org.apache.qpid.broker">
<class name="Broker">
and 'broker just a shorthand. but could be be done with expanded tags.
we could also add a shorthand for acl ...
Currently the ACL schema for C++ broker lives at
/qpid/cpp/src/qpid/acl/management-schema.xml
if was put here as it was not known at the time if would be used by both brokers, it sounds like we may
want to consider moving up to /specs // add anything that is missing from the Java side.
Note that clustering also has it's own schema as do most of the modules, we could move schema up
as required.
For logging we don't have that exposed in the QMF objects on the C++ side, but that
would be a nice addition. If we added a logging schema, then it would be acl'ed
something like
acl allow ADMIN all schemapackage=org.apache.qpid.acl
if you only wanted to allow the setting of a specific log level, then that per definition
is an METHOD/EXECUTE and that would be written something like this (making it up as no
QMF schema is written down anywhere for logging. (inheritance pattern)
group debugusers carl, adk
acl allow debugusers execute setLogDebug schemapackage=org.apache.qpid.acl
of delegation pattern (add 'scope' or something like that tag
group debugusers carl, adk
acl allow debugusers execute setLogDebug scope=org.apache.qpid.acl
As much of the debate is around logging, I think we need to define the QMF object for
setting logging, and then come back to this discussion.
If you like, happy to find time to IRC or talk abit on the topic.
What I am pushing back on is that broker 'does not' have subsystems. There are acl schema's
that exist in or out of process with other schema object/ and you should 'address' the acl either
based on the package name or schema in most cases.
Thus if we add logging ACL QMF schema, it should be able to turn logging on/off/level for any
schema package. That level of setting would require work on the C++ side, but seems meaningful.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Andrew Kennedy <an...@gmail.com>.
On 17 May 2010 17:43, Carl Trieloff <cc...@redhat.com> wrote:
>
> part I am confused about in the thread is the following: Why introduce
> additional opperations to the ACL file format when they can already
> be covered with what is already in the format?
>
> I can see why we need to add (vhost, subnetmask) -- no argument there.
> owner - I'm not 100% sure on but seems reasonable
>
> I don't see why any of the other additions are needed (config, admin,
> connect,..). I'm not saying we should not cover x case, I just don't see
> yet why it is not covered with what is already there.
>
> If we can't cover with what is there, adding is fine, but I'm not convinced
> yet that they are needed to cover any of the cases put forward so far in
> the JIRA.
OK, the IP whitelisting/firewalling is a separate issue, but here is my
summary of the proposal I have for new ACL methods. I'd appreciate
comments. Also, Rajith, could you append the following text to the wiki
page you're creating, since I don't have access, please?
== METHOD considered harmful ==
A lot of the object types and operations used in the ACL file are shared
between the Java and C++ brokers and are non-contentious, since they
represent actual objects that exist in AMQP - broker, queue, exchange
and so forth. What appears to be at issue is how to permission extra
funtionality in the broker, such as administration of user accounts or
logging levels The C++ broker's 'METHOD' object is one mechanism, and
results in ACL lines that specify a single method or set of methods that
can be executed, and does not convey whether these are reading, writing
or have other side effects on the broker. An example is shoen below:
ACL ALLOW adk UPDATE METHOD name=getLoggingLevel
ACL ALLOW adk UPDATE METHOD name=setLoggingLevel
ACL ALLOW adk UPDATE METHOD name=reloadLoggingConfig
This seems to be at the wrong level of abstraction. Looking at this
in a general fashion, there are three things we wish to do to objects:
get a property, set a property and execute an operation. These can be
mapped to READ, WRITE, EXECUTE or GET, SET, INVOKE, ACCESS, UPDATE,
ADMIN, and so on as operations. The next step would be to decide what
the object type is that is being manipulated. I would be happy for this
to be one of the existing AMQP objects, including BROKER, since this
follows the existing pattern of permissions. Another point to note is
that existing mechanisms such as JMX already have the conceptual split
into these three types of action.
If we abandon the METHOD object in favour of existing object types, we
still need to be able to permission such items as users and logging, and
I propose these are made part of the broker object, with the possibility
of adding other, vendor-specific extensions too. This would result in ACL
lines as shown below, which would grant permission to view attributes
of the logging subsystem, update those attributes and execute other
administrative actions. Finally, if there is a management schema change
and the names of methods used change, or new methods and attributes are
added, the ACL file does not have to be changed, since the permissions
relate to subsystems or extensions.
ACL ALLOW adk ACCESS BROKER extension=logging
ACL ALLOW adk UPDATE BROKER extension=logging
ACL ALLOW adk ADMIN BROKER extension=logging
or
ACL ALLOW adk ADMIN BROKER subsystem=acl
If we want to create an ACL file format that is usable across AMQP
brokers, then the use of 'extension=<name>' or 'subsystem=<name>' with
a set of pre-defined names, say 'logging', 'users', 'configuration',
and a naming convention to prevent clashes, such as 'x-<vendor>-*'
for vendor specific implementations or just 'x-*' for experimental
extensions/subsystems seems appropriate.
Thanks,
adk.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by Carl Trieloff <cc...@redhat.com>.
Don't know if this is a debate or not, pieces we all understand and
agree to.
We need to be able to do IP whitlisting
We need to be able support certain classes of oppertaions
We need vhost
....
In ACLv2 as the C++ broker, most of the cases can be covered
with the config. There is even a patch on JIRA for whitelisting
for the C++ broker (needs tests etc).
part I am confused about in the thread is the following: Why introduce
additional opperations to the ACL file format when they can already
be covered with what is already in the format?
I can see why we need to add (vhost, subnetmask) -- no argument there.
owner - I'm not 100% sure on but seems reasonable
I don't see why any of the other additions are needed (config, admin,
connect,..). I'm
not saying we should not cover x case, I just don't see yet why it is
not covered
with what is already there.
If we can't cover with what is there, adding is fine, but I'm not
convinced yet that
they are needed to cover any of the cases put forward so far in the JIRA.
Carl.
On 05/17/2010 11:11 AM, Robert Godfrey wrote:
> Sorry to come late to this discussion... Just thought that I'd add
> that in addition to Marnie's points below wrt virtual hosts (which in
> themselves should be considered compelling), it is not completely true
> to say that AMQP1-0 removes Virtual Hosts, it is just that we say that
> if you do them, you should do them in a more "httpd" like way (i.e.
> the notion of virtual host is tied into the host name that you believe
> you have connected to).
>
> It is still envisioned that in AMQP1-0 a single broker "process" may
> be acting as if it were several independent hosts - as to whether you
> would wish to manage all the ACLs for the independent hosts in the
> same file... that is a different question. The reason for doing so in
> an AMQP0-x broker is that authentication is done *before* selecting
> the vhost. In 1-0 the host would potentially be selected prior to
> authentication.
>
> -- Rob
>
> On 14 May 2010 22:33, Marnie McCormack<ma...@googlemail.com> wrote:
>
>> We have real customer requirements for both the virtual host level ACLs,
>> where prod deployments restrict incoming clients to one vh only, but allow
>> all artifacts on that vh for that user. We also need to retain the firewall,
>> or at least the config/features, since that was a priority feature
>> enhancement which we need to continue supporting,
>>
>> Hth,
>> Marnie
>>
>> On Tue, May 11, 2010 at 3:37 PM, Rajith Attapattu (JIRA)<
>> qpid-dev@incubator.apache.org> wrote:
>>
>>
>>> [
>>> https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866162#action_12866162]
>>>
>>> Rajith Attapattu commented on QPID-2539:
>>> ----------------------------------------
>>>
>>> 1. I can see the value of virtual host for the current setup, but going
>>> forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late
>>> in the game?
>>>
>>> I am not opposed to having a virtual host object in the ACL file as the
>>> Java broker is using that.
>>> The c++ broker can easily ignore it.
>>> My question was more about whether it's really worth spending effort on
>>> something that we know want be there for long.
>>> If you have customer requests for protecting virtual hosts with ACL then it
>>> is fine (All though I think this is redundant as the objects within a
>>> virtual host is covered anyways).
>>> But if there is no interest from the users, then I'd say don't bother.
>>>
>>> ADK: This is required for the Firewall plugin. Whether the Firewall plugin
>>> is required is another question entirely.
>>>
>>> RA: Good question, Aidan and I had discussed on the qpid dev list about
>>> using ACL to validate the IP addresses instead of maintaining a separate
>>> firewall plugin.
>>> The C++ broker does have an outstanding JIRA for something similar
>>> to the firewall plugin which we hope to implement using ACL.
>>> We were planning to have that as an optional feature to ensure
>>> backwards compatibility.
>>>
>>> So if you want ACL to restrict IP address you need to explicitly
>>> enable it in the ACL module.
>>> The config option (Not the CONFIG object) you talked about is going
>>> to be handy here.
>>>
>>> I am bit swamped these days, hopefully when I get some free time, I will
>>> try to put my thoughts into a wiki page to capture the requirements and
>>> share some ideas with you.
>>> Perhaps then we can open some more concrete JIRA's to focus on those
>>> individual areas.
>>>
>>>
>>>> Update ACL file syntax to be clearer and add extra operations
>>>> -------------------------------------------------------------
>>>>
>>>> Key: QPID-2539
>>>> URL: https://issues.apache.org/jira/browse/QPID-2539
>>>> Project: Qpid
>>>> Issue Type: Sub-task
>>>> Components: Java Broker
>>>> Reporter: Andrew Kennedy
>>>> Fix For: 0.7
>>>>
>>>>
>>>>
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Robert Godfrey <ro...@gmail.com>.
Sorry to come late to this discussion... Just thought that I'd add
that in addition to Marnie's points below wrt virtual hosts (which in
themselves should be considered compelling), it is not completely true
to say that AMQP1-0 removes Virtual Hosts, it is just that we say that
if you do them, you should do them in a more "httpd" like way (i.e.
the notion of virtual host is tied into the host name that you believe
you have connected to).
It is still envisioned that in AMQP1-0 a single broker "process" may
be acting as if it were several independent hosts - as to whether you
would wish to manage all the ACLs for the independent hosts in the
same file... that is a different question. The reason for doing so in
an AMQP0-x broker is that authentication is done *before* selecting
the vhost. In 1-0 the host would potentially be selected prior to
authentication.
-- Rob
On 14 May 2010 22:33, Marnie McCormack <ma...@googlemail.com> wrote:
> We have real customer requirements for both the virtual host level ACLs,
> where prod deployments restrict incoming clients to one vh only, but allow
> all artifacts on that vh for that user. We also need to retain the firewall,
> or at least the config/features, since that was a priority feature
> enhancement which we need to continue supporting,
>
> Hth,
> Marnie
>
> On Tue, May 11, 2010 at 3:37 PM, Rajith Attapattu (JIRA) <
> qpid-dev@incubator.apache.org> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866162#action_12866162]
>>
>> Rajith Attapattu commented on QPID-2539:
>> ----------------------------------------
>>
>> 1. I can see the value of virtual host for the current setup, but going
>> forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late
>> in the game?
>>
>> I am not opposed to having a virtual host object in the ACL file as the
>> Java broker is using that.
>> The c++ broker can easily ignore it.
>> My question was more about whether it's really worth spending effort on
>> something that we know want be there for long.
>> If you have customer requests for protecting virtual hosts with ACL then it
>> is fine (All though I think this is redundant as the objects within a
>> virtual host is covered anyways).
>> But if there is no interest from the users, then I'd say don't bother.
>>
>> ADK: This is required for the Firewall plugin. Whether the Firewall plugin
>> is required is another question entirely.
>>
>> RA: Good question, Aidan and I had discussed on the qpid dev list about
>> using ACL to validate the IP addresses instead of maintaining a separate
>> firewall plugin.
>> The C++ broker does have an outstanding JIRA for something similar
>> to the firewall plugin which we hope to implement using ACL.
>> We were planning to have that as an optional feature to ensure
>> backwards compatibility.
>>
>> So if you want ACL to restrict IP address you need to explicitly
>> enable it in the ACL module.
>> The config option (Not the CONFIG object) you talked about is going
>> to be handy here.
>>
>> I am bit swamped these days, hopefully when I get some free time, I will
>> try to put my thoughts into a wiki page to capture the requirements and
>> share some ideas with you.
>> Perhaps then we can open some more concrete JIRA's to focus on those
>> individual areas.
>>
>> > Update ACL file syntax to be clearer and add extra operations
>> > -------------------------------------------------------------
>> >
>> > Key: QPID-2539
>> > URL: https://issues.apache.org/jira/browse/QPID-2539
>> > Project: Qpid
>> > Issue Type: Sub-task
>> > Components: Java Broker
>> > Reporter: Andrew Kennedy
>> > Fix For: 0.7
>> >
>> >
>>
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be
clearer and add extra operations
Posted by Marnie McCormack <ma...@googlemail.com>.
We have real customer requirements for both the virtual host level ACLs,
where prod deployments restrict incoming clients to one vh only, but allow
all artifacts on that vh for that user. We also need to retain the firewall,
or at least the config/features, since that was a priority feature
enhancement which we need to continue supporting,
Hth,
Marnie
On Tue, May 11, 2010 at 3:37 PM, Rajith Attapattu (JIRA) <
qpid-dev@incubator.apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866162#action_12866162]
>
> Rajith Attapattu commented on QPID-2539:
> ----------------------------------------
>
> 1. I can see the value of virtual host for the current setup, but going
> forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late
> in the game?
>
> I am not opposed to having a virtual host object in the ACL file as the
> Java broker is using that.
> The c++ broker can easily ignore it.
> My question was more about whether it's really worth spending effort on
> something that we know want be there for long.
> If you have customer requests for protecting virtual hosts with ACL then it
> is fine (All though I think this is redundant as the objects within a
> virtual host is covered anyways).
> But if there is no interest from the users, then I'd say don't bother.
>
> ADK: This is required for the Firewall plugin. Whether the Firewall plugin
> is required is another question entirely.
>
> RA: Good question, Aidan and I had discussed on the qpid dev list about
> using ACL to validate the IP addresses instead of maintaining a separate
> firewall plugin.
> The C++ broker does have an outstanding JIRA for something similar
> to the firewall plugin which we hope to implement using ACL.
> We were planning to have that as an optional feature to ensure
> backwards compatibility.
>
> So if you want ACL to restrict IP address you need to explicitly
> enable it in the ACL module.
> The config option (Not the CONFIG object) you talked about is going
> to be handy here.
>
> I am bit swamped these days, hopefully when I get some free time, I will
> try to put my thoughts into a wiki page to capture the requirements and
> share some ideas with you.
> Perhaps then we can open some more concrete JIRA's to focus on those
> individual areas.
>
> > Update ACL file syntax to be clearer and add extra operations
> > -------------------------------------------------------------
> >
> > Key: QPID-2539
> > URL: https://issues.apache.org/jira/browse/QPID-2539
> > Project: Qpid
> > Issue Type: Sub-task
> > Components: Java Broker
> > Reporter: Andrew Kennedy
> > Fix For: 0.7
> >
> >
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867467#action_12867467 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
Missed this, too:
RA: 1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason ?
ADK: NAME is used as the name of the object specified in the rule. When binding a queue to an exchange the queue name is set as QUEUE_NAME as well.
RA: 2. What exactly does OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR means ?
ADK: OWNER is queue owner, INTERNAL is a property referenced when creating exchanges, TEMPORARY is a synonym for AUTO_DELETE. Actually, TCP_SESSION and REMOTE_ADDR are not require.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866171#action_12866171 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
I couldn't find any documentation of the METHOD object, and it is not listed on the ACL web page. Could someone list the way this is currently used, and give some example ACL lines to illustrate?
Cheers,
Andrew.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866182#action_12866182 ]
Rajith Attapattu commented on QPID-2539:
----------------------------------------
I see that Carl had already put up an example.
Andrew could you also put up a wiki page with your proposals and use examples.
You could then post the link in the description section.
That will help a lot to avoid going back and forth to clarify certain points.
Also it will help folks who will join the discussion mid way through.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Kennedy updated QPID-2539:
---------------------------------
Attachment: (was: acl.txt)
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Kennedy updated QPID-2539:
---------------------------------
Attachment: acl.txt
correct file
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Kennedy updated QPID-2539:
---------------------------------
Attachment: acl.txt
Forgot to add this before. I have updated it with some details of the discussion.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867465#action_12867465 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
The reason I used MANAGE was that the type of operation is not determined by the object or the operation, but by the name of the method, so the operation token has no meaning.
This would also interfere with the ability to add e.g. CREATE QUEUE permission and have that be meaningful when accessing the broker via the management interfaces. I am more in favour of abandoning the METHOD based mechanism, in favour of enumerating the objects that can be accessed via the management interfaces and adding ACCESS and UPDATE, possibly ADMIN/MANAGE operations to them where possible.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866127#action_12866127 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game?
This is required for the Firewall plugin. Whether the Firewall plugin is required is another question entirely.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875107#action_12875107 ]
Rajith Attapattu commented on QPID-2539:
----------------------------------------
Marnie,
All though we discussed, I do not think we agreed on a concrete proposal yet.
I believe there are still some open questions that didn't quite get resolved.
I am also working on a proposal which I am hoping to get out by tomorrow.
So I'd appreciate if we keep this JIRA open until we get some sort of agreement.
Regards,
Rajith
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866165#action_12866165 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
1. What is the purpose of CONNECT ?
ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation.
RA: In that case why not use "ACCESS" which is already there ?
ADK: I just checked, and it turns out I am using ACCESS, exactly as you say. I have removed CONNECT now.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866124#action_12866124 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
RA: Is this to improve readability? I am not sure what exactly the benefit here?
ADK: The whitespace and continuation definitions are to both improve readability and to make parsing simpler. I could easily restict whitespace back to the old set, but see no problem with extending it as longas it is well defined. As for continuation lines, if they are supported in one place, why not just support them everywhere, rather than the confusing (perhaps) rules about where exactly they can be placed. Every language that allows continuation characters for line breaking simply allows them anywhere and joins the two lines, ignoring the continuation character, I just wanted to follow the existing convention.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866184#action_12866184 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
acl allow admin admin log # allow JMX/QMF log level administration
This means that the log4j logger's level is able to be changed from, e.g. INFO to DEBUG, or a new logging configuration file can be loaded, I don't believe it is equivalent to:
acl allow admin access all
Also, you use METHOD as both an object and an operation - it isn't clear what the difference between, say, access method and update method would be?
acl allow admin method all # should there be an update or an access before the method?
acl allow admin update method reloadACLFile
Would these not be clearer as:
acl allow admin access method name=* # access to all methods
acl allow admin access method name=reloadACLFile # access to a single method
or even:
acl allow admin manage broker method=*
acl allow admin manage broker method=reloadACLFile
I will update the document I'm writing with the results of this discussion and post a link.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Kennedy updated QPID-2539:
---------------------------------
Parent: QPID-2476
Issue Type: Sub-task (was: Task)
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865809#action_12865809 ]
Rajith Attapattu commented on QPID-2539:
----------------------------------------
My comments are marked with "RA"
The changes are cosmetic, mostly, and would (admittedly) have the result of breaking Java to C++ compatibility, although C++ ACL files would remain parseable by the Java broker. The file format specification would have three types of declarations: group, acl or config, which I will describe below. Additionally, there are common features among these declarations.
-------------
RA:
1. I'd like to emphasize again that there should not be a separate c++ and java ACL file formats. We should have one and only one ACL file format for Qpid brokers. If we agree to make changes, then both brokers would need to support it.
There are users who are already trying to use both C++ and Java brokers (using federation) in production. Having a single file format makes life very easy here.
2. Qpid as project is aiming to provide a consistent experience across all brokers and clients. This is a vision and a goal of this project. Individual features should be developed with this in mind.
3. IMO having a strict format is better, as it is simple and less ambiguous, resulting in far less errors. Also rigid format is better for a security related to system to prevent people from exploiting the lenient nature of the format to exploit any gaps.
----------------
1. Whitespace is considered to be any ASCII byte with a value below 0x20, and is ignored when it occurs between tokens.
2. Continuations using the '\' character (ASCII 0x5c) are allowed anywhere on a line, and can consist of a blank line with a continuation character as the lat non-whitespace token
---------
RA: Is this to improve readability? I am not sure what exactly the benefit here?
----------
3. Comments are line-style comments, and any text after an un-quoted '#' (ASCII 0x23) are ignored, including continuations. The '#' charater may appear in a quoted string.
RA: I think this is useful. We need to allow comments.
4. Quoted strings consist of any ASCII inside matching pairs of ''' or '"' (ASCII 0x27 and 0x22) characters, including any otherwise special characters.
5. Tokens are *NOT* case sensitive, but quoted strings *ARE*.
6. The '=' (ASCII 0x3d) character is special, and is used to indicate property value assignment.
7. Wildcards are specified using the '*' (ASCII 0x2a) character in a property value string, which may be quoted.
The declarations are as follows, using some kind of grammar, with + and * having the usual regular expression meanings, parenthesis denote grouping and brackets denote optional elements.
CONFIG ( <config-property> '=' <TRUE | FALSE> ) +
GROUP <group-name> ( <username | group-name> ) +
[ <number> ] ACL <permission> <username | group-name | ALL> <operation> [ <object-type> ( <property-name> '=' <property-value> ) * ]
This allows a rather looser and more readable style for ACL files, while still retaining the ability to read the stricter files accepted by the C++ broker. Bear in mind that the group declarations are to be deprecated, in favour of an external directory service, using a plugin mechanism.
-------------------
RA:
1. I don't think we should deprecate the "group" declarations. I think it's a very convenient feature and is currently used by several customers that in production.
2. I am not opposed to having a pluggable external mechanism for configuring groups. However I am still not clear as to how these groups are tied to the authentication system. Bear in mind that the users in ACL are authenticated via our authentication mechanism. So any external mechanism used for the groups needs to be used in authentication as well. Could you pls clarify this point?
3. I like the config option. There are several use cases that can benefit from this. I will note them down when I have a bit more time.
4. IMO there is no point having a relaxed format for Java broker and a strict format for C++. There should be a single format for both. Some of the changes you have mentioned are sensible and useful and I don't think they break backwards compatibility. So I see no reason why they shouldn't be incorporated.
----------------
The initial <number> is used to allow rulesets to be created which allow indicidual rules to be enabled and disabled using an admin interface, and an ACL file using numbered lines would be restricted to having increasing numbers per rule, although gaps would be allowed to enable rules to be inserted later, again using an admin interface. This administrative interface would also allow saving of a modified ruleset and re-loading.
Additionally, the following operations, object types and property names are defined, some of which are not present in the C++ implementation:
Operation: ALL, CONSUME, PUBLISH, CREATE, ACCESS, CONNECT, BIND, UNBIND, DELETE, PURGE, UPDATE, ADMIN
-----------
RA:
1. What is the purpose of CONNECT ?
2. What is the purpose of ADMIN ?
----------
ObjectType: ALL, VIRTUALHOST, QUEUE, TOPIC, EXCHANGE, BROKER, LINK, ROUTE, METHOD, USER, LOG, CONFIG, ACL
-----------
RA:
1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game?
2. What is the purpose of LOG, CONFIG and ACL ?
I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind.
3. Also how is LOG different from "allow-log" and "deny-log" in the current format ?
----------
Property: ROUTING_KEY, NAME, QUEUE_NAME, OWNER, TYPE, ALTERNATE, INTERNAL, NO_WAIT, NO_LOCAL, NO_ACK, PASSIVE, DURABLE, EXCLUSIVE, TEMPORARY, AUTO_DELETE, TCP_SESSION, REMOTE_ADDR
---------------
RA:
1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason ?
2. What exactly does OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR means ?
--------------
There are restrictions on the combinations of Operations and ObjectTypes, as well as which Properties can be used to specify an ObjectType. I will attach a more detailed document on these restrictions, which I am working on at the moment, describing the use cases that are covered.
Andrew.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866162#action_12866162 ]
Rajith Attapattu commented on QPID-2539:
----------------------------------------
1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game?
I am not opposed to having a virtual host object in the ACL file as the Java broker is using that.
The c++ broker can easily ignore it.
My question was more about whether it's really worth spending effort on something that we know want be there for long.
If you have customer requests for protecting virtual hosts with ACL then it is fine (All though I think this is redundant as the objects within a virtual host is covered anyways).
But if there is no interest from the users, then I'd say don't bother.
ADK: This is required for the Firewall plugin. Whether the Firewall plugin is required is another question entirely.
RA: Good question, Aidan and I had discussed on the qpid dev list about using ACL to validate the IP addresses instead of maintaining a separate firewall plugin.
The C++ broker does have an outstanding JIRA for something similar to the firewall plugin which we hope to implement using ACL.
We were planning to have that as an optional feature to ensure backwards compatibility.
So if you want ACL to restrict IP address you need to explicitly enable it in the ACL module.
The config option (Not the CONFIG object) you talked about is going to be handy here.
I am bit swamped these days, hopefully when I get some free time, I will try to put my thoughts into a wiki page to capture the requirements and share some ideas with you.
Perhaps then we can open some more concrete JIRA's to focus on those individual areas.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866122#action_12866122 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
1. I'd like to emphasize again that there should not be a separate c++ and java ACL file formats. We should have one and only one ACL file format for Qpid brokers. If we agree to make changes, then both brokers would need to support it.
There are users who are already trying to use both C++ and Java brokers (using federation) in production. Having a single file format makes life very easy here.
2. Qpid as project is aiming to provide a consistent experience across all brokers and clients. This is a vision and a goal of this project. Individual features should be developed with this in mind.
3. IMO having a strict format is better, as it is simple and less ambiguous, resulting in far less errors. Also rigid format is better for a security related to system to prevent people from exploiting the lenient nature of the format to exploit any gaps.
ADK: I agree. The 'less strict' phrasing was not the best choice of words. The file format I'm proposing still has no ambiguity, and can be defined with a strict EBNF grammar (if so desired ;) and is simply an extension of the C++ format, i.e. any valid C++ broker ACL file is also a valid Java broker ACL file. The opposite is not true, since at the moment there are features (virtualhosts) that are not available in the C++ broker. Actually, this can be dealt with the same way the java broker deals with currently un-implemented features (routes, links) by ignoring those ACL stanzas.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866177#action_12866177 ]
Carl Trieloff commented on QPID-2539:
-------------------------------------
RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc..
However I am wondering how much of config is going to overlap with QMF.
On C++ side is is done like this:
<class name="Acl">
<property name="brokerRef" type="objId" references="org.apache.qpid.broker:Broker" access="RO" index="y" parentRef="y"/>
<property name="policyFile" type="sstr" access="RO" desc="Name of the policy file"/>
<property name="enforcingAcl" type="bool" access="RO" desc="Currently Enforcing ACL"/>
<property name="transferAcl" type="bool" access="RO" desc="Any transfer ACL rules in force"/>
<property name="lastAclLoad" type="absTime" access="RO" desc="Timestamp of last successful load of ACL"/>
<statistic name="aclDenyCount" type="count64" unit="request" desc="Number of ACL requests denied"/>
<method name="reloadACLFile" desc="Reload the ACL file"/>
</class>
Then the normal ACL action perissions are applied to the method, allowing you to set permissions of who may reload the ACL's. Reason it is 'METHOD' is that it ACL's applied to QMF methods....
-->
I don't have any preference between ADMIN or MANGE, but I prefer both of those to METHOD. Also, to me this is an operation and the object types I suggested would then allow ACL lines like this:
ACL ALLOW admin ADMIN BROKER # allow JMX/QMF access to read-only management attributes on the broker
ACL ALLOW admin ADMIN CONFIG # allow JMX/QMF administration of configuration file reloading
ACL ALLOW admin ADMIN LOG # allow JMX/QMF log level administration
ACL ALLOW admin ADMIN USER # allow JMX/QMF user administration
<--
For example
group admin (......)
acl allow admin method all # allow admin group access to all QMF / JMX methods.
acl allow admin access all # equivalent of your LOG level statement.
acl allow admin update method reloadACLFile # allow admin group to update acl file.
I believe they are all covered already.
Carl.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865168#action_12865168 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
Sorry for the delay in adding this...
The changes are cosmetic, mostly, and would (admittedly) have the result of breaking Java to C++ compatibility, although C++ ACL files would remain parseable by the Java broker. The file format specification would have three types of declarations: group, acl or config, which I will describe below. Additionally, there are common features among these declarations.
1. Whitespace is considered to be any ASCII byte with a value below 0x20, and is ignored when it occurs between tokens.
2. Continuations using the '\' character (ASCII 0x5c) are allowed anywhere on a line, and can consist of a blank line with a continuation character as the lat non-whitespace token
3. Comments are line-style comments, and any text after an un-quoted '#' (ASCII 0x23) are ignored, including continuations. The '#' charater may appear in a quoted string.
4. Quoted strings consist of any ASCII inside matching pairs of ''' or '"' (ASCII 0x27 and 0x22) characters, including any otherwise special characters.
5. Tokens are *NOT* case sensitive, but quoted strings *ARE*.
6. The '=' (ASCII 0x3d) character is special, and is used to indicate property value assignment.
7. Wildcards are specified using the '*' (ASCII 0x2a) character in a property value string, which may be quoted.
The declarations are as follows, using some kind of grammar, with + and * having the usual regular expression meanings, parenthesis denote grouping and brackets denote optional elements.
CONFIG ( <config-property> '=' <TRUE | FALSE> ) +
GROUP <group-name> ( <username | group-name> ) +
[ <number> ] ACL <permission> <username | group-name | ALL> <operation> [ <object-type> ( <property-name> '=' <property-value> ) * ]
This allows a rather looser and more readable style for ACL files, while still retaining the ability to read the stricter files accepted by the C++ broker. Bear in mind that the group declarations are to be deprecated, in favour of an external directory service, using a plugin mechanism.
The initial <number> is used to allow rulesets to be created which allow indicidual rules to be enabled and disabled using an admin interface, and an ACL file using numbered lines would be restricted to having increasing numbers per rule, although gaps would be allowed to enable rules to be inserted later, again using an admin interface. This administrative interface would also allow saving of a modified ruleset and re-loading.
Additionally, the following operations, object types and property names are defined, some of which are not present in the C++ implementation:
Operation: ALL, CONSUME, PUBLISH, CREATE, ACCESS, CONNECT, BIND, UNBIND, DELETE, PURGE, UPDATE, ADMIN
ObjectType: ALL, VIRTUALHOST, QUEUE, TOPIC, EXCHANGE, BROKER, LINK, ROUTE, METHOD, USER, LOG, CONFIG, ACL
Property: ROUTING_KEY, NAME, QUEUE_NAME, OWNER, TYPE, ALTERNATE, INTERNAL, NO_WAIT, NO_LOCAL, NO_ACK, PASSIVE, DURABLE, EXCLUSIVE, TEMPORARY, AUTO_DELETE, TCP_SESSION, REMOTE_ADDR
There are restrictions on the combinations of Operations and ObjectTypes, as well as which Properties can be used to specify an ObjectType. I will attach a more detailed document on these restrictions, which I am working on at the moment, describing the use cases that are covered.
Andrew.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867496#action_12867496 ]
Carl Trieloff commented on QPID-2539:
-------------------------------------
Rajith,
I don't see PROP_OWNER actually used anywhere on the code base, can that be removed?
Then for IP Whitelisting, what props does that patch add?
Carl.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866217#action_12866217 ]
Carl Trieloff commented on QPID-2539:
-------------------------------------
I miss-typed the one example, method is an object.
I really don't get why you keep putting in 'manage' -- what does that mean - access, update, delete ? or all of them?
Carl.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867517#action_12867517 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
PROP_SCHEMAPACKAGE, PROP_SCHEMACLASS, PROP_POLICYTYPE, PROP_MAXQUEUESIZE, PROP_MAXQUEUECOUNT
Can someone explain what these do, please?
Also, regarding OWNER, this has meaning with the Java broker, so should be kept (perhaps unused) for symmetry between formats.
ADK.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866125#action_12866125 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
RA:
1. I don't think we should deprecate the "group" declarations. I think it's a very convenient feature and is currently used by several customers that in production.
2. I am not opposed to having a pluggable external mechanism for configuring groups. However I am still not clear as to how these groups are tied to the authentication system. Bear in mind that the users in ACL are authenticated via our authentication mechanism. So any external mechanism used for the groups needs to be used in authentication as well. Could you pls clarify this point?
ADK: This is to allow other mechanisms, primarily directory services but also stand-alone group files, such as the unix /etc/group file. I have no problem keepin the ability to include groups in the ACL file, I would just like to have the ability to override this facility and use an external, pluggable mechanism. In many cases this will be separate from the authentication mechanism by their very nature - unix passwd and group is an obvious example, as is .htaccess and tomcat groups. We should continue discussion at QPID-2541 though.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866149#action_12866149 ]
Rajith Attapattu commented on QPID-2539:
----------------------------------------
RA: Is this to improve readability? I am not sure what exactly the benefit here?
ADK: The whitespace and continuation definitions are to both improve readability and to make parsing simpler. I could easily restict whitespace back to the old set, but see no problem with extending it as longas it is well defined. As for continuation lines, if they are supported in one place, why not just support them everywhere, rather than the confusing (perhaps) rules about where exactly they can be placed. Every language that allows continuation characters for line breaking simply allows them anywhere and joins the two lines, ignoring the continuation character, I just wanted to follow the existing convention.
RA: I am totally fine with the whitespace, my comment was more about continuations. Sorry for not making that clear.
Could you perhaps provide an example of what is allowed and not allowed with the proposed changes for continuations ?
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867521#action_12867521 ]
Carl Trieloff commented on QPID-2539:
-------------------------------------
PROP_MAXQUEUESIZE, PROP_MAXQUEUECOUNT --- queue depth on queue creation via ACL. used by selfservice users who want users to be able to declare a queue but only get a pre-defined or less queue size.
package and class refer to QMF, so you can scope ACL to any QMF method.
What is OWNER used for in the Java broker?
Carl.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Resolved: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack resolved QPID-2539.
------------------------------------
Resolution: Fixed
Proposal discussed with community, esp Rajith & Carl - see doc links on parent JIRA for detailed proposal output.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866166#action_12866166 ]
Carl Trieloff commented on QPID-2539:
-------------------------------------
Is ADMIN not just a group of users with a specifc set of permissions assigned?
Is CONNECT not just allow access virtualhost ?
I think LOG is already covered with METHOD, maybe we should walk through an example for JMX admin and QMF Admin and see if it covers all the cases that are being thought about. If not we should add those to the METHOD call.
" LOG allows changing the log4j levels and USER grants the ability to add/delete users. " Is use not an broker tangental concept. I know Java broker supports a user create call. In my view with QMF, this should be modeled with a QMF user schema and then if that object is supplied by the broker or something external it makes no diff.
The all the permissions can be applied to all the methods on that schema using the METHOD object. This would keep things 100% consistent. i.e. controlling setting log level, adding users etc all sound like METHOD permissions.
Carl.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866188#action_12866188 ]
Carl Trieloff commented on QPID-2539:
-------------------------------------
I think the thread can be summed as follows:
- The acl v2 mechinism can most likely handle all if not all the cases, (maybe a few minor things are missing).
- From the Java side, they have a few defined (groups/roles) with specific predefined permissions.
I think the debate will come down to -- should we include a set of 'qpid-defined' named roles with permissions set. The approach on the C++ side has been to allow the user to create what he needs. But having a few predefined groups (even if just shipped in the default acl file) that may be meaningful.
Carl.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866147#action_12866147 ]
Rajith Attapattu commented on QPID-2539:
----------------------------------------
ADK: I agree. The 'less strict' phrasing was not the best choice of words. The file format I'm proposing still has no ambiguity, and can be defined with a strict EBNF grammar (if so desired ;) and is simply an extension of the C++ format, i.e. any valid C++ broker ACL file is also a valid Java broker ACL file. The opposite is not true, since at the moment there are features (virtualhosts) that are not available in the C++ broker. Actually, this can be dealt with the same way the java broker deals with currently un-implemented features (routes, links) by ignoring those ACL stanzas.
RA: I think we should really stop thinking in terms of a java format or c++ format. We need to focus on agreeing on a common format.
Once we decide and agree on a format both brokers **should** be able to parse the file format.
However each broker could ignore items that it doesn't support.
Also when we document, we need to ensure that we position this as the "Qpid ACL format".
Then we can go onto mention the exceptions where each broker may ignore certain entries.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Issue Comment Edited: (QPID-2539) Update ACL file syntax to
be clearer and add extra operations
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866166#action_12866166 ]
Carl Trieloff edited comment on QPID-2539 at 5/11/10 10:49 AM:
---------------------------------------------------------------
Is ADMIN not just a group of users with a specifc set of permissions assigned?
Is CONNECT not just allow access virtualhost ?
I think LOG is already covered with METHOD, maybe we should walk through an example for JMX admin and QMF Admin and see if it covers all the cases that are being thought about. If not we should add those to the METHOD call.
" LOG allows changing the log4j levels and USER grants the ability to add/delete users. " Is use not a broker tangental concept. I know Java broker supports a user create call. In my view with QMF, this should be modeled with a QMF user schema and then if that object is supplied by the broker or something external it makes no diff.
Then all the permissions can be applied to all the methods on that schema using the METHOD object. This would keep things 100% consistent. i.e. controlling setting log level, adding users etc all sound like METHOD permissions.
Carl.
was (Author: cctrieloff):
Is ADMIN not just a group of users with a specifc set of permissions assigned?
Is CONNECT not just allow access virtualhost ?
I think LOG is already covered with METHOD, maybe we should walk through an example for JMX admin and QMF Admin and see if it covers all the cases that are being thought about. If not we should add those to the METHOD call.
" LOG allows changing the log4j levels and USER grants the ability to add/delete users. " Is use not an broker tangental concept. I know Java broker supports a user create call. In my view with QMF, this should be modeled with a QMF user schema and then if that object is supplied by the broker or something external it makes no diff.
The all the permissions can be applied to all the methods on that schema using the METHOD object. This would keep things 100% consistent. i.e. controlling setting log level, adding users etc all sound like METHOD permissions.
Carl.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Carl Trieloff (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867490#action_12867490 ]
Carl Trieloff commented on QPID-2539:
-------------------------------------
Martin,
Yes, I just sudo'ed them out from memory. If you want me to update them to be precise, I can do that.
Andrew,
RA: 1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason ?
For acl on Bindings. (acl for bind / unbind)
NAME is the exchange name
(make_pair(acl::PROP_QUEUENAME, queueName)); ---- QUEUENAME is the queue name
t(make_pair(acl::PROP_ROUTINGKEY, routingKey));
in regards to OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR -- I don't see most these in the source code, where
did you get them from ?? It might be from when Aidan was working ACLv2 for the Java broker? or from a Acl patch yet committed (Rajith?)
Here is the full list supported currently by the C++ code base from AclModle.h
enum ObjectType {OBJ_QUEUE, OBJ_EXCHANGE, OBJ_BROKER, OBJ_LINK,
OBJ_METHOD, OBJECTSIZE}; // OBJECTSIZE must be last in list
enum Action {ACT_CONSUME, ACT_PUBLISH, ACT_CREATE, ACT_ACCESS, ACT_BIND,
ACT_UNBIND, ACT_DELETE, ACT_PURGE, ACT_UPDATE,
ACTIONSIZE}; // ACTIONSIZE must be last in list
enum Property {PROP_NAME, PROP_DURABLE, PROP_OWNER, PROP_ROUTINGKEY,
PROP_PASSIVE, PROP_AUTODELETE, PROP_EXCLUSIVE, PROP_TYPE,
PROP_ALTERNATE, PROP_QUEUENAME, PROP_SCHEMAPACKAGE,
PROP_SCHEMACLASS, PROP_POLICYTYPE, PROP_MAXQUEUESIZE,
PROP_MAXQUEUECOUNT};
enum AclResult {ALLOW, ALLOWLOG, DENY, DENYLOG};
note OBJECTSIZE ACTIONSIZE are not types, just part of the parser code.
Carl.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
> Attachments: acl.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866158#action_12866158 ]
Rajith Attapattu commented on QPID-2539:
----------------------------------------
1. What is the purpose of CONNECT ?
ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation.
RA: In that case why not use "ACCESS" which is already there ?
2. What is the purpose of ADMIN ?
2. What is the purpose of LOG, CONFIG and ACL ?
I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind.
3. Also how is LOG different from "allow-log" and "deny-log" in the current format ?
ADK: An ACL that allows JMX (or QMF) administration to take place, where the object being administered is either the BROKER (i.e. to retrieve queue names, statistics, read-only attributes and so on) or CONFIG, LOG or USER. These three are only modifiable using the admin interface, wheras the other ACL entries apply (like CREATE QUEUE) no matter how the queue is created.
RA: We already have a BROKER object.
And we already have "METHOD" for QMF, which I think nicely covers JMX as well.
If you need to query a queue name, then that is protected by the QUEUE object.
In ACL, each object defines it's own access control list. So I didn't really understand the role of the "ACL" object. in the context you described.
Besides ACL module does not add/modify users. That is the responsibility of the authentication mechanism defined using SASL.
So not sure what the "USER" object is supposed to do.
CONFIG grants permission to reload the security config, or edit ACL lines,
RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc..
However I am wondering how much of config is going to overlap with QMF.
For example the C++ broker is using QMF to reload the ACL file.
So reloading of the ACL file is actually protected under the "METHOD" object.
As I mentioned before, METHOD can cover both QMF and JMX. However I really dislike the name :)
Perhaps we can have a meaningful name here. Maybe ADMIN (or MGT) instead of METHOD ?
LOG allows changing the log4j levels and USER grants the ability to add/delete users.
RA: Instead of using a separate top level object can we not have this under the purview of the MGT or ADMIN (previously METHOD) object and the properties to define the file name, log level etc..
But I am also not really opposed to having a top level LOG object either.
I'd be interested to hear opinions from a wider audience as well.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866170#action_12866170 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc..
However I am wondering how much of config is going to overlap with QMF.
For example the C++ broker is using QMF to reload the ACL file.
So reloading of the ACL file is actually protected under the "METHOD" object.
As I mentioned before, METHOD can cover both QMF and JMX. However I really dislike the name :)
Perhaps we can have a meaningful name here. Maybe ADMIN (or MGT) instead of METHOD ?
LOG allows changing the log4j levels and USER grants the ability to add/delete users.
RA: Instead of using a separate top level object can we not have this under the purview of the MGT or ADMIN (previously METHOD) object and the properties to define the file name, log level etc..
But I am also not really opposed to having a top level LOG object either.
I'd be interested to hear opinions from a wider audience as well.
ADK:
FYI, there is no ACL object, that may have been a typo.
I don't have any preference between ADMIN or MANGE, but I prefer both of those to METHOD. Also, to me this is an operation and the object types I suggested would then allow ACL lines like this:
ACL ALLOW admin ADMIN BROKER # allow JMX/QMF access to read-only management attributes on the broker
ACL ALLOW admin ADMIN CONFIG # allow JMX/QMF administration of configuration file reloading
ACL ALLOW admin ADMIN LOG # allow JMX/QMF log level administration
ACL ALLOW admin ADMIN USER # allow JMX/QMF user administration
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860279#action_12860279 ]
Rajith Attapattu commented on QPID-2539:
----------------------------------------
Andrew, have you had a chance to look at http://qpid.apache.org/acl.html ?
If you have, could you please explain what improvements you would like to make ?
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Andrew Kennedy (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866126#action_12866126 ]
Andrew Kennedy commented on QPID-2539:
--------------------------------------
1. What is the purpose of CONNECT ?
ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation.
2. What is the purpose of ADMIN ?
2. What is the purpose of LOG, CONFIG and ACL ?
I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind.
3. Also how is LOG different from "allow-log" and "deny-log" in the current format ?
ADK: An ACL that allows JMX (or QMF) administration to take place, where the object being administered is either the BROKER (i.e. to retrieve queue names, statistics, read-only attributes and so on) or CONFIG, LOG or USER. These three are only modifiable using the admin interface, wheras the other ACL entries apply (like CREATE QUEUE) no matter how the queue is created. CONFIG grants permission to reload the security config, or edit ACL lines, LOG allows changing the log4j levels and USER grants the ability to add/delete users.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer
and add extra operations
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867458#action_12867458 ]
Martin Ritchie commented on QPID-2539:
--------------------------------------
Carl,
In your reloadACLFile example are you not missing the property name?
According to the ACLv2 spec on the wiki that, we both worked on, your example should be more like:
acl allow admin update method name=reloadACLFile # allow admin group to update acl file.
Wiki Spec for ACLv2
acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all"] [property=<property-value>]
Does the C++ broker allow this line?
acl allow admin update method reloadACLFile
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org