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 <y...@novell.com> > Software Engineer > China Server Team, OPS Engineering, Novell, Inc. > > > _______________________________________________ > Pacemaker mailing list > Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker _______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
