[Pacemaker] Multi-level ACLs for the CIB

[Tim Serong]

On 2/4/2010 at 02:52 PM, Yan Gao <ygao at novell.com> wrote: 
>  
> Andrew Beekhof wrote: 
> > On Tue, Feb 2, 2010 at 6:14 AM, Yan Gao <ygao at novell.com> wrote: 
> >  
> > [snip] 
> >  
> >> A configuration example: 
> >> .. 
> >> <acls> 
> >>  <role id="operator"> 
> >>    <write id="operator-write-0" tag="nodes"/> 
> >>    <write id="operator-write-1" tag="status"/> 
> >>  </role> 
> >>  <role id="monitor"> 
> >>    <read id="monitor-read-0" tag="nodes"/> 
> >>    <read id="monitor-read-1" tag="status"/> 
> >>  </role> 
> >  
> > [snip] 
> >  
> > Quick question, have you tried using crm_mon with a configuration like  
> this? 
> > I'm pretty sure you'll get nothing sensible as it can't find the resources. 
> Indeed. I ever thought that the information from "<status..." could be enough 
> for monitoring, while then realized both of the nodes and resources from 
> "<configuration..." are required. 
>  
> >  
> > Might want to think about how to deal with that... 
> We could either give some well defined ACLs for that, or is it possible that 
> crm_mon doesn't dependent on the info from "configration"? 
 
I don't think so...  cib/configuration/resources etc. is the canonical
source for what's configured, and may include things for which there is
no status information yet.  There's nothing in cib/status yet, for example,
if the cluster is just starting up, yet crm_mon will still show you the
configured nodes and resources.  I've followed the same logic with Hawk,
too, i.e. I'm interrogating cib/configuration to see what's meant to be
there, then later check cib/status to see if it actually is.

Default ACL that grants everyone read access to configuration, maybe?

Regards,

Tim


-- 
Tim Serong <tserong at novell.com>
Senior Clustering Engineer, Novell Inc.