[Pacemaker] Multi-level ACLs for the CIB

[Dejan Muhamedagic]

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")? 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.

> 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? The way it is
now, it's also hard to follow.

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

Cheers,

Dejan