[Pacemaker] Multi-level ACLs for the CIB
Dejan Muhamedagic
dejanmm at fastmail.fm
Wed Jan 13 12:53:55 UTC 2010
Hi Yan,
On Wed, Jan 13, 2010 at 08:49:00PM +0800, Yan Gao wrote:
> Dejan Muhamedagic wrote:
> > Hi,
> >
> > On Wed, Jan 13, 2010 at 10:04:12AM +0100, Andrew Beekhof wrote:
> > [...]
> >>>>>>> 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.
> >> I don't think you want that.
> >> "One user, one role" would be my advice.
> >
> > Wouldn't that be too restrictive?
> How about removing the "members" in role, while preserving the multiple
> references of roles ?
That would do, of course. For whatever reason, however,
specifying members along with the role seems more natural to me.
> >> Otherwise you have all sorts of potentially non-obvious cases to deal with.
> >> Like if roleA allows modification of an attribute and roleB disallows
> >> it, and the user has both.
> >
> > First match wins: the result is undefined, i.e. depends on the
> > order of roles. Which we apparently don't have. Unless the member
> > element is dropped in favour of role references.
> >
> >> Seriously, make the admin do the normalization (otherwise you have to
> >> do it for every invocation which is going to slow you down).
> >>
> >> This is the schema I'd suggest
> >>
> >> + <define name="element-acls">
> >> + <element name="acls">
> >> + <zeroOrMore>
> >> + <choice>
> >> + <element name="user">
> >> + <attribute name="id"><text/></attribute>
> >> + <choice>
> >> + <attribute name="role"><data type="IDREF"/></attribute>
> >> + <zeroOrMore>
> >> + <ref name="element-acl"/>
> >> + </zeroOrMore>
> >> + </ichoice>
> >> + </element>
> >> + <element name="role">
> >> + <attribute name="id"><data type="ID"/></attribute>
> >> + <zeroOrMore>
> >> + <ref name="element-acl"/>
> >> + </zeroOrMore>
> >> + </element>
> >> + </choice>
> >> + </zeroOrMore>
> >> + </element>
> >> + </define>
> >>
> >> In english:
> >> - Roles have ACLs
> >> - Users can be assigned EITHER a role OR a set of ACLs
> >
> > This is a further simplification. Though it would make the
> > configuration more straightforward and easier to understand.
> Ok. Once we have a consensus on all of the issues, I'll post
> the updated schema including the ACL support for "attribute" later
> for you to confirm.
It would be great if somebody who had to deal with such a scheme
would share their experience with us.
Thanks,
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
More information about the Pacemaker
mailing list