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