[Pacemaker] Multi-level ACLs for the CIB

[Dejan Muhamedagic]

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.

> > 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:)

OK. Let's hope we get some idea :)

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

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

Looks good to me.

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

Cheers,

Dejan

> Thanks,
>   Yan
> -- 
> Yan Gao <ygao at novell.com>
> Software Engineer
> China Server Team, OPS Engineering, Novell, Inc.
> 
> 
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker