[Pacemaker] Multi-level ACLs for the CIB

[Andrew Beekhof]

On Wed, Jan 13, 2010 at 6:21 AM, Yan Gao <ygao at novell.com> wrote:
> Dejan Muhamedagic wrote:
>> 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.
> I think it would be better to introduce xpath as Andrew suggested.
> That would be precise enough.
>
>>
>>>>> 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.

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.

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


Oh, and can you explain this please:

+	  <choice>
+	    <attribute name="ref"><data type="IDREF"/></attribute>
+	    <attribute name="tag"><text/></attribute>
+	    <group>
+	      <attribute name="ref"><data type="IDREF"/></attribute>
+	      <attribute name="tag"><text/></attribute>
+	    </group>
+	  </choice>

Why would you want a reference and a tag?