[Pacemaker] Multi-level ACLs for the CIB

[Andrew Beekhof]

On Wed, Dec 9, 2009 at 11:00 AM, Yan Gao <ygao at novell.com> wrote:
> Hi Andrew, Lars,
>
> On 12/08/09 21:16, Lars Marowsky-Bree wrote:
>> 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.
> Actually, after thinking over the problem, I'm a bit confused...So I
> briefly describe what in my mind, please correct me if there's any problem.
>
> First, currently non-root users are able to connect the cib through
> either unix or network sockets as long as they belong to "haclient"
> group. We could keep this requirement.
>
> Then the cib should authenticate the client via PAM to identify who is
> connecting to it.

Thats what I'm saying, it can only do this for the hacluster user.
Because its not running as root.

> Otherwise the daemon could not determine who the
> client is really running as, not the who he claim he is, right?
>
> Though even if the cib has the right to authenticate users,

It doesn't.

> users would
> need to be prompted their own username/password again when they connect
> a client to cib, after logging into a shell. And perhaps they would need
> to be prompted every time they run a client later, unless we implement a
> mechanism like "sudo".
>
> I noticed several environments such as "CIB_user" and "CIB_password" are
> introduced for remote access to cib .  Should we adopt that for local
> access too?

Probably for CIB_user but not CIB_password.
I shouldn't have added that one.

>
>>
>>>>        <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.
> Agreed.
>
> Thanks,
>  Yan
> --
> ygao at novell.com
> Software Engineer
> China Server Team, OPS Engineering
>
> Novell, Inc.
> Making IT Work As One™
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>