On 17 May 2010 17:43, Carl Trieloff <[email protected]> wrote:
>
> part I am confused about in the thread is the following: Why introduce
> additional opperations to the ACL file format when they can already
> be covered with what is already in the format?
>
> I can see why we need to add (vhost, subnetmask) -- no argument there.
> owner - I'm not 100% sure on but seems reasonable
>
> I don't see why any of the other additions are needed (config, admin,
> connect,..). I'm not saying we should not cover x case, I just don't see
> yet why it is not covered with what is already there.
>
> If we can't cover with what is there, adding is fine, but I'm not convinced
> yet that they are needed to cover any of the cases put forward so far in
> the JIRA.
OK, the IP whitelisting/firewalling is a separate issue, but here is my
summary of the proposal I have for new ACL methods. I'd appreciate
comments. Also, Rajith, could you append the following text to the wiki
page you're creating, since I don't have access, please?
== METHOD considered harmful ==
A lot of the object types and operations used in the ACL file are shared
between the Java and C++ brokers and are non-contentious, since they
represent actual objects that exist in AMQP - broker, queue, exchange
and so forth. What appears to be at issue is how to permission extra
funtionality in the broker, such as administration of user accounts or
logging levels The C++ broker's 'METHOD' object is one mechanism, and
results in ACL lines that specify a single method or set of methods that
can be executed, and does not convey whether these are reading, writing
or have other side effects on the broker. An example is shoen below:
ACL ALLOW adk UPDATE METHOD name=getLoggingLevel
ACL ALLOW adk UPDATE METHOD name=setLoggingLevel
ACL ALLOW adk UPDATE METHOD name=reloadLoggingConfig
This seems to be at the wrong level of abstraction. Looking at this
in a general fashion, there are three things we wish to do to objects:
get a property, set a property and execute an operation. These can be
mapped to READ, WRITE, EXECUTE or GET, SET, INVOKE, ACCESS, UPDATE,
ADMIN, and so on as operations. The next step would be to decide what
the object type is that is being manipulated. I would be happy for this
to be one of the existing AMQP objects, including BROKER, since this
follows the existing pattern of permissions. Another point to note is
that existing mechanisms such as JMX already have the conceptual split
into these three types of action.
If we abandon the METHOD object in favour of existing object types, we
still need to be able to permission such items as users and logging, and
I propose these are made part of the broker object, with the possibility
of adding other, vendor-specific extensions too. This would result in ACL
lines as shown below, which would grant permission to view attributes
of the logging subsystem, update those attributes and execute other
administrative actions. Finally, if there is a management schema change
and the names of methods used change, or new methods and attributes are
added, the ACL file does not have to be changed, since the permissions
relate to subsystems or extensions.
ACL ALLOW adk ACCESS BROKER extension=logging
ACL ALLOW adk UPDATE BROKER extension=logging
ACL ALLOW adk ADMIN BROKER extension=logging
or
ACL ALLOW adk ADMIN BROKER subsystem=acl
If we want to create an ACL file format that is usable across AMQP
brokers, then the use of 'extension=<name>' or 'subsystem=<name>' with
a set of pre-defined names, say 'logging', 'users', 'configuration',
and a naming convention to prevent clashes, such as 'x-<vendor>-*'
for vendor specific implementations or just 'x-*' for experimental
extensions/subsystems seems appropriate.
Thanks,
adk.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
