[Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

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.


> Would there be a big performance penalty?

> 
>>         <read id="ygao-read-0" ref="rsc0"/>
>>         <role_ref id="operator"/>
>>       </user>
>>     </acls>
>> ..
> 
> Do you have a suggestion how to spell out acls in the crm shell
> syntax? We should also create a real-life acl configuration and
> then see how that can be represented.
I've been thinking about it, but haven't got an clear idea now:)

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

It can be either of them in configuration, and must not be both of them.
That also could avoid the confusing case which I demonstrated in the example.

So how about the syntax like:

role <id> acl_obj [acl_obj ...]

user <id> {acl_obj | ref_role} [{acl_obj | ref_role} ...]

user <id> is <role_id>

acl_obj ::
  mode ref <ref_id>
  mode tag <tag_name>
  mode ref <ref_id> tag <tag_name>

mode:: read | write | deny

ref_role:: ref_role <role_id>


> 
>> [...]
>> The first command is achieved by requesting lrmd, which is running as root,
>> to do the cleanup for the client. So it could always bypass the ACL check.
> 
> lrmd is not running as root, but as nobody. And it's not a
> client to the cib. 
Right, my bad. it should be crmd which is running as the privileged user -- "hacluster".

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

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