Andrew Beekhof wrote: > On Tue, Jan 12, 2010 at 10:41 AM, Dejan Muhamedagic <deja...@fastmail.fm> > wrote: >> Hi, >> >> On Mon, Jan 11, 2010 at 09:01:30PM +0800, Yan Gao wrote: > > Ah, I was looking in the patch. > >>> <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. > > Agreed. > Not to mention that the admin wouldn't be able to remove the attribute > anymore (since its referenced in the acl). > >> 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? > > Probably simplest to just support xpath: > > <deny id="gaoyan-deny-0" xpath="//[...@id='rsc0']//[...@name='password']"/> The only concern to introduce xpath was the complexity of the syntax. If we are OK with that, I can implement also :-)
> >>> <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. > > Agreed. I think I prefer the latter. > >>> [...] >>> 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? > > Check the diff? It now does check the diff. Besides the "__crm_diff_marker__" set for add/remove, I also add a marker for "modified". But one modification could modify several of its attributes. So for recognizing those, we might need to add multiple markers for one element? > If you do that after the operation but before the activation, you'd be > able to veto and invalid changes. > So you'd not even need to pre-filter the input cib or query. It does pre-filter only for a query operation. If an user queries cib with a xpath, and the result is multiple objects listed under a "<xpath-query>", it could not accomplish the filter unless we pre-filter the input cib. 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