[Pacemaker] Multi-level ACLs for the CIB

Lars Marowsky-Bree lmb at suse.de
Tue Dec 8 08:16:55 EST 2009


On 2009-12-08T09:22:52, Andrew Beekhof <andrew at beekhof.net> wrote:

> > Basically, we'd like to see an ACL mechanism. It would be implemented at
> > the CIB level. So that all the clients - CLI , CRM shell, GUI, etc... -
> > could benefit. Clients are authenticated via PAM, so we can use uid/gid
> > for identification.
> 
> Actually you probably can't do this.
> Daemons (like the cib) which are not running as root can only
> authenticate the username/password of the user they're running as.

Well, the non-root internal uids/daemons would of course get exceptions
just like root, this is about external interfaces.

> >        <deny ref="stonith1-instance_attributes-ilo_password" />
> >        <read ref="stonith1" />
> >        <read ref="#status" />
> Please, no hashes here.

This stems from the fact that the status XML element doesn't have an id;
but for general access to specific sections (XML elements) it may be
worth adding a section=(...) attribute instead of a special prefix in
the ref="" attribute.

> > I think the syntax isn't perfect yet, but that should be the basic
> > direction. I'd like to hear your thoughts about it.
> Seems reasonable.
> I do worry about how big the acls section is going to grow though.

Well, that is of course going to depend on the complexity of the
customer/user needs.

> If you can keep the overhead to near zero for the root/no-acls case,
> then I'd not be too concerned about being able to compile it out.

Cool, thanks!

Definitely, the root/internal & no-acls case should be "0" and boil down
to a simple, trivial if().


Regards,
    Lars

-- 
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde





More information about the Pacemaker mailing list