Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
Thanks Rajith - sounds like a good plan. Appreciate your time, Marnie On Thu, Jun 3, 2010 at 3:41 PM, Rajith Attapattu wrote: > On Thu, Jun 3, 2010 at 10:32 AM, Marnie McCormack > 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 > 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 > >> 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-...@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-subscr...@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-subscr...@qpid.apache.org > >> > >> > > > > > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > > - > Apache Qpid - AMQP Messaging Impl
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On Thu, Jun 3, 2010 at 10:32 AM, Marnie McCormack 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 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 >> 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-...@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-subscr...@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-subscr...@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-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
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 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 > 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-...@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-subscr...@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-subscr...@qpid.apache.org > >
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
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 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-...@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-subscr...@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-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
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-...@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-subscr...@qpid.apache.org > >
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 19 May 2010 17:22, Carl Trieloff 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-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 05/19/2010 12:30 PM, Andrew Kennedy wrote: On 19 May 2010 17:22, Carl Trieloff 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-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 19 May 2010 17:22, Carl Trieloff 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-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
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 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}
{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 me
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 18 May 2010 14:52, Rajith Attapattu 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}
{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
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On Tue, May 18, 2010 at 7:13 AM, Andrew Kennedy wrote: > On 17 May 2010 17:43, Carl Trieloff 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-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 05/18/2010 07:13 AM, Andrew Kennedy wrote: On 17 May 2010 17:43, Carl Trieloff 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=' or 'subsystem=' with a set of pre-defined names, say 'logging', 'users', 'configuration', and a naming convention to prevent clashes, such as 'x--*' 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 schemapac
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 17 May 2010 17:43, Carl Trieloff 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=' or 'subsystem=' with a set of pre-defined names, say 'logging', 'users', 'configuration', and a naming convention to prevent clashes, such as 'x--*' 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-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
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 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-...@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
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
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 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-...@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-subscr...@qpid.apache.org >> >> > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
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-...@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-subscr...@qpid.apache.org > >
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 14 May 2010 16:19, Rajith Attapattu 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-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
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) 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-subscr...@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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[
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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[
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 {||"all"} {action|"all"} [object|"all"]
[property=]
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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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: 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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 ( '=' ) + GROUP ( ) + [ ] ACL[ ( '=' ) * ] 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 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
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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 ( '=' ) + GROUP ( ) + [ ] ACL[ ( '=' ) * ] 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 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-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ 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-subscr...@qpid.apache.org
