[
https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865809#action_12865809
]
Rajith Attapattu commented on QPID-2539:
----------------------------------------
My comments are marked with "RA"
The changes are cosmetic, mostly, and would (admittedly) have the result of
breaking Java to C++ compatibility, although C++ ACL files would remain
parseable by the Java broker. The file format specification would have three
types of declarations: group, acl or config, which I will describe below.
Additionally, there are common features among these declarations.
-------------
RA:
1. I'd like to emphasize again that there should not be a separate c++ and
java ACL file formats. We should have one and only one ACL file format for Qpid
brokers. If we agree to make changes, then both brokers would need to support
it.
There are users who are already trying to use both C++ and Java brokers (using
federation) in production. Having a single file format makes life very easy
here.
2. Qpid as project is aiming to provide a consistent experience across all
brokers and clients. This is a vision and a goal of this project. Individual
features should be developed with this in mind.
3. IMO having a strict format is better, as it is simple and less ambiguous,
resulting in far less errors. Also rigid format is better for a security
related to system to prevent people from exploiting the lenient nature of the
format to exploit any gaps.
----------------
1. Whitespace is considered to be any ASCII byte with a value below 0x20, and
is ignored when it occurs between tokens.
2. Continuations using the '\' character (ASCII 0x5c) are allowed anywhere on a
line, and can consist of a blank line with a continuation character as the lat
non-whitespace token
---------
RA: Is this to improve readability? I am not sure what exactly the benefit
here?
----------
3. Comments are line-style comments, and any text after an un-quoted '#' (ASCII
0x23) are ignored, including continuations. The '#' charater may appear in a
quoted string.
RA: I think this is useful. We need to allow comments.
4. Quoted strings consist of any ASCII inside matching pairs of ''' or '"'
(ASCII 0x27 and 0x22) characters, including any otherwise special characters.
5. Tokens are *NOT* case sensitive, but quoted strings *ARE*.
6. The '=' (ASCII 0x3d) character is special, and is used to indicate property
value assignment.
7. Wildcards are specified using the '*' (ASCII 0x2a) character in a property
value string, which may be quoted.
The declarations are as follows, using some kind of grammar, with + and *
having the usual regular expression meanings, parenthesis denote grouping and
brackets denote optional elements.
CONFIG ( <config-property> '=' <TRUE | FALSE> ) +
GROUP <group-name> ( <username | group-name> ) +
[ <number> ] ACL <permission> <username | group-name | ALL> <operation> [
<object-type> ( <property-name> '=' <property-value> ) * ]
This allows a rather looser and more readable style for ACL files, while still
retaining the ability to read the stricter files accepted by the C++ broker.
Bear in mind that the group declarations are to be deprecated, in favour of an
external directory service, using a plugin mechanism.
-------------------
RA:
1. I don't think we should deprecate the "group" declarations. I think it's a
very convenient feature and is currently used by several customers that in
production.
2. I am not opposed to having a pluggable external mechanism for configuring
groups. However I am still not clear as to how these groups are tied to the
authentication system. Bear in mind that the users in ACL are authenticated via
our authentication mechanism. So any external mechanism used for the groups
needs to be used in authentication as well. Could you pls clarify this point?
3. I like the config option. There are several use cases that can benefit from
this. I will note them down when I have a bit more time.
4. IMO there is no point having a relaxed format for Java broker and a strict
format for C++. There should be a single format for both. Some of the changes
you have mentioned are sensible and useful and I don't think they break
backwards compatibility. So I see no reason why they shouldn't be incorporated.
----------------
The initial <number> is used to allow rulesets to be created which allow
indicidual rules to be enabled and disabled using an admin interface, and an
ACL file using numbered lines would be restricted to having increasing numbers
per rule, although gaps would be allowed to enable rules to be inserted later,
again using an admin interface. This administrative interface would also allow
saving of a modified ruleset and re-loading.
Additionally, the following operations, object types and property names are
defined, some of which are not present in the C++ implementation:
Operation: ALL, CONSUME, PUBLISH, CREATE, ACCESS, CONNECT, BIND, UNBIND,
DELETE, PURGE, UPDATE, ADMIN
-----------
RA:
1. What is the purpose of CONNECT ?
2. What is the purpose of ADMIN ?
----------
ObjectType: ALL, VIRTUALHOST, QUEUE, TOPIC, EXCHANGE, BROKER, LINK, ROUTE,
METHOD, USER, LOG, CONFIG, ACL
-----------
RA:
1. I can see the value of virtual host for the current setup, but going forward
do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game?
2. What is the purpose of LOG, CONFIG and ACL ?
I think CONFIG is probably a good addition, but I'd like to understand
what exactly you had in mind.
3. Also how is LOG different from "allow-log" and "deny-log" in the current
format ?
----------
Property: ROUTING_KEY, NAME, QUEUE_NAME, OWNER, TYPE, ALTERNATE, INTERNAL,
NO_WAIT, NO_LOCAL, NO_ACK, PASSIVE, DURABLE, EXCLUSIVE, TEMPORARY, AUTO_DELETE,
TCP_SESSION, REMOTE_ADDR
---------------
RA:
1. I am not sure we need both NAME and QUEUE_NAME. Was there a specific reason
?
2. What exactly does OWNER, INTERNAL, TEMPORARY, TCP_SESSION, REMOTE_ADDR
means ?
--------------
There are restrictions on the combinations of Operations and ObjectTypes, as
well as which Properties can be used to specify an ObjectType. I will attach a
more detailed document on these restrictions, which I am working on at the
moment, describing the use cases that are covered.
Andrew.
> Update ACL file syntax to be clearer and add extra operations
> -------------------------------------------------------------
>
> Key: QPID-2539
> URL: https://issues.apache.org/jira/browse/QPID-2539
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Broker
> Reporter: Andrew Kennedy
> Fix For: 0.7
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
