On 2009-12-08T09:22:52, Andrew Beekhof <and...@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
_______________________________________________
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
