[Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

Dejan Muhamedagic wrote:
> Hi,
> 
> On Tue, Jan 12, 2010 at 08:00:56PM +0800, Yan Gao wrote:
>> Hi Dejan,
>>
>> Dejan Muhamedagic wrote:
>>> Hi,
>>>
>>> On Mon, Jan 11, 2010 at 09:01:30PM +0800, Yan Gao wrote:
>>>> ..
>>>>     <acls>
>>>>       <role id="admin">
>>>>         <write id="admin-write-0" tag="configuration"/>
>>>>         <write id="admin-write-1" tag="status"/>
>>>>       </role>
>>>>       <role id="operator">
>>>>         <write id="operator-write-0" tag="nodes"/>
>>>>         <write id="operator-write-1" tag="status"/>
>>>>       </role>
>>>>       <role id="monitor">
>>>>         <read id="operator-read-0" tag="nodes"/>
>>>>         <read id="monitor-read-1" tag="status"/>
>>>>         <members>
>>>>           <uid id="ygao"/>
>>>>         </members>
>>>>       </role>
>>>>       <user id="ygao">
>>>>         <write id="ygao-write-0" ref="rsc0-meta_attributes-target-role"/>
>>>>         <deny id="gaoyan-deny-0" ref="rsc0-instance_attributes-password"/>
>>> I understand that the "ref" element references some "id", but
>>> note that the attributes's ids are sort of volatile. In
>>> particular the meta attributes. Can we somehow reference the
>>> attributes themselves (in this case "password" and
>>> "target-role")? 
>> It might not make it clear, because there could be multiple nvpairs with the
>> same "name" in different attribute sets. Even they could be under a single resource,
>> for example some of the attributes sets contain specific rules.
> 
> But that shouldn't matter. By setting reference to the attribute
> name, the user clearly indicates what they want. If there are
> multiple elements with the same attribute, it should apply to all
> of them.
I think it would be better to introduce xpath as Andrew suggested.
That would be precise enough.

> 
>>>> The user "ygao" is a system account.
>>>> We could define several roles as we wish, such as "admin",
>>>> "operator" and "monitor", which could contain a member list
>>>> respectively if more than one user have the same permissions. A
>>>> role also could be referenced by a particular "<user ...>"
>>>> definition.
>>> I find this a bit confusing: roles have members and users can
>>> reference roles. Shouldn't one of the two suffice? 
>> An user can reference one or more roles to combine the rules with his
>> particular definition. But if several users  are supposed to have the
>> completely same permissions, the "members" under a "role" could avoid
>> to define the users via separated "<user ..." one by one.
>>
>>> The way it is
>>> now, it's also hard to follow.
>> What if to separate it into two cases for an user definition in crm shell:
>> 1. "is" a role
>> 2. "ref" one role or more roles.
> 
> But, let's try to forget for a moment the shell or CRM in general.
> I'm trying to understand why a role reference makes things
> better. Actually, it would be great if you could give an example
> which would clearly show an advantage of such use.
For example:
User A has the right to operate rsc1, while user B has the right to
operate rsc2. Besides that, we might want to grant them some other same
permissions, for instance allowing them to monitor the status of the cluster.
So we could define a common role "monitor" for reference instead
of defining similar rules repeatedly.

A ideal way in my mind is that we provide some templates with
common roles pre-defined for user's convenience to reference.

>>> But I guess that it is not relevant.
>>>> BTW, there're some changes comparing to the original design:
>>>> [...]
>>>> There could be an "attribute" for an ACL object in the original design :
>>>> <write id=... ref="rsc0-meta_attributes-target-role" attribute="value" />
>>>>
>>>> it was supposed to mean user could only write the "value" attribute of
>>>> "rsc0-meta_attributes-target-role" element.
>>>>
>>>> I didn't implement it because there's no good way for now for the ACL
>>>> checker to recognize if a modification would change/add/remove any
>>>> particular attributes of a XML element. And I'm thinking if it's
>>>> necessary to implement it... Your thoughts?
>>> OK, I suppose that I commented on this above :) If it is a
>>> problem to implement it here, then we may try to do that in the
>>> crm shell, i.e. it would lookup the attribute name and then
>>> create the right ref id.
>> Great!
> 
> Well, that would not be optimal: let's not forget that shell use
> is not required.
Right. If an user works with XML, xpath would not be hard to use
for him :)

Regards,
  Yan
-- 
Yan Gao <ygao at novell.com>
Software Engineer
China Server Team, OPS Engineering, Novell, Inc.