On 05/18/2010 07:13 AM, Andrew Kennedy wrote:
On 17 May 2010 17:43, Carl Trieloff<cctriel...@redhat.com> wrote:
part I am confused about in the thread is the following: Why introduce
additional opperations to the ACL file format when they can already
be covered with what is already in the format?
I can see why we need to add (vhost, subnetmask) -- no argument there.
owner - I'm not 100% sure on but seems reasonable
I don't see why any of the other additions are needed (config, admin,
connect,..). I'm not saying we should not cover x case, I just don't see
yet why it is not covered with what is already there.
If we can't cover with what is there, adding is fine, but I'm not convinced
yet that they are needed to cover any of the cases put forward so far in
the JIRA.
OK, the IP whitelisting/firewalling is a separate issue, but here is my
summary of the proposal I have for new ACL methods. I'd appreciate
comments. Also, Rajith, could you append the following text to the wiki
page you're creating, since I don't have access, please?
== METHOD considered harmful ==
A lot of the object types and operations used in the ACL file are shared
between the Java and C++ brokers and are non-contentious, since they
represent actual objects that exist in AMQP - broker, queue, exchange
and so forth. What appears to be at issue is how to permission extra
funtionality in the broker, such as administration of user accounts or
logging levels The C++ broker's 'METHOD' object is one mechanism, and
results in ACL lines that specify a single method or set of methods that
can be executed, and does not convey whether these are reading, writing
or have other side effects on the broker. An example is shoen below:
ACL ALLOW adk UPDATE METHOD name=getLoggingLevel
ACL ALLOW adk UPDATE METHOD name=setLoggingLevel
ACL ALLOW adk UPDATE METHOD name=reloadLoggingConfig
This seems to be at the wrong level of abstraction. Looking at this
in a general fashion, there are three things we wish to do to objects:
get a property, set a property and execute an operation. These can be
mapped to READ, WRITE, EXECUTE or GET, SET, INVOKE, ACCESS, UPDATE,
ADMIN, and so on as operations. The next step would be to decide what
the object type is that is being manipulated. I would be happy for this
to be one of the existing AMQP objects, including BROKER, since this
follows the existing pattern of permissions. Another point to note is
that existing mechanisms such as JMX already have the conceptual split
into these three types of action.
If we abandon the METHOD object in favour of existing object types, we
still need to be able to permission such items as users and logging, and
I propose these are made part of the broker object, with the possibility
of adding other, vendor-specific extensions too. This would result in ACL
lines as shown below, which would grant permission to view attributes
of the logging subsystem, update those attributes and execute other
administrative actions. Finally, if there is a management schema change
and the names of methods used change, or new methods and attributes are
added, the ACL file does not have to be changed, since the permissions
relate to subsystems or extensions.
ACL ALLOW adk ACCESS BROKER extension=logging
ACL ALLOW adk UPDATE BROKER extension=logging
ACL ALLOW adk ADMIN BROKER extension=logging
or
ACL ALLOW adk ADMIN BROKER subsystem=acl
If we want to create an ACL file format that is usable across AMQP
brokers, then the use of 'extension=<name>' or 'subsystem=<name>' with
a set of pre-defined names, say 'logging', 'users', 'configuration',
and a naming convention to prevent clashes, such as 'x-<vendor>-*'
for vendor specific implementations or just 'x-*' for experimental
extensions/subsystems seems appropriate.
Some of your reasoning is good, some I don't agree with.
if we use
READ, WRITE, EXECUTE
then
METHOD today == EXECUTE
or
GET, SET, INVOKE, ACCESS, UPDATE
then
METHOD today == INVOKE
that seems like a reasonable rename.
Being able to apply ACL at a single method level is required. If you want to
apply ACL to section of the ACL schema, then you can do that. For example for
broker, queue, xyz, or foobar. The schema tag allows you to do that.
thus schema in the C++ broker today seems to be equivalent to the extension/
subsystem
command but cleaner as it maps directly to any QMF schema object we decide to
create.
However, the following command makes NO sense
ACL ALLOW adk ADMIN BROKER subsystem=acl
First ADMIN is not a command, should not be. it could be a group with
permissions
Then BROKER and subsystem=acl make no sense together / have no idea how to
implement this, it is assuming
acl is sub broker, which it is not. I understand what you are trying to do,
but the relationships are not
right.
If you look at the schema (broker& acl are separate objects), it would be
written like this.
group ADMIN adk
acl allow ADMIN all schemapackage=org.apache.qpid.acl
note that broker is actually
<schema package="org.apache.qpid.broker">
<class name="Broker">
and 'broker just a shorthand. but could be be done with expanded tags.
we could also add a shorthand for acl ...
Currently the ACL schema for C++ broker lives at
/qpid/cpp/src/qpid/acl/management-schema.xml
if was put here as it was not known at the time if would be used by both
brokers, it sounds like we may
want to consider moving up to /specs // add anything that is missing from the
Java side.
Note that clustering also has it's own schema as do most of the modules, we
could move schema up
as required.
For logging we don't have that exposed in the QMF objects on the C++ side, but
that
would be a nice addition. If we added a logging schema, then it would be acl'ed
something like
acl allow ADMIN all schemapackage=org.apache.qpid.acl
if you only wanted to allow the setting of a specific log level, then that per
definition
is an METHOD/EXECUTE and that would be written something like this (making it
up as no
QMF schema is written down anywhere for logging. (inheritance pattern)
group debugusers carl, adk
acl allow debugusers execute setLogDebug schemapackage=org.apache.qpid.acl
of delegation pattern (add 'scope' or something like that tag
group debugusers carl, adk
acl allow debugusers execute setLogDebug scope=org.apache.qpid.acl
As much of the debate is around logging, I think we need to define the QMF
object for
setting logging, and then come back to this discussion.
If you like, happy to find time to IRC or talk abit on the topic.
What I am pushing back on is that broker 'does not' have subsystems. There are
acl schema's
that exist in or out of process with other schema object/ and you should
'address' the acl either
based on the package name or schema in most cases.
Thus if we add logging ACL QMF schema, it should be able to turn logging
on/off/level for any
schema package. That level of setting would require work on the C++ side, but
seems meaningful.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
