[Pacemaker] Multi-level ACLs for the CIB

Yan Gao ygao at novell.com
Tue Jan 12 03:12:08 EST 2010


Hi Andrew,

Andrew Beekhof wrote:
> On Mon, Jan 11, 2010 at 2:01 PM, Yan Gao <ygao at novell.com> wrote:
>> Hi all, Andrew, Lars,
>>
>> Here's the status update about this feature.
>>
>> I've implemented the main functionalities of ACL, including the ACLs
>> configuration parser, the CIB output filter and the modification checker...
>>
>> Yan Gao wrote:
>>> On 12/09/09 18:28, Andrew Beekhof wrote:
>>>> 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.
>>> Indeed, that's the real problem. Without authentication, that would not
>>> be a real access control. No idea if there's any other solution... Lars,
>>> what's your recommendation?
>> For this authentication issue of local access we discussed last time, I
>> added a geteuid() in the cib_native_signon_raw() function from libcib.
>> Once a client signs on the CIB, it'll invoke the function and transfer
>> its uid to the server end.
> 
> I don't see anywhere that the server checks passwords.  Is that really
> intentional?
Yes for now, before we have a good solution to do authentication.

> 
>> Strictly speaking, an user could hack his client program or libcib to
>> obtain the privileged right to CIB. But he also could hack the server
>> end, right? ;-)
> 
> Or use a local (modified) copy of libcib, or just bypass it altogether.
> Both of which are far more trivial than installing modified code on
> the server-side.
Right, I think so too.

> 
> Whats the role of this code, is it meant to provide actual security?
> Or is it just casual protection from people accidentally touching
> stuff they probably didn't mean to touch?
I think the latter is the main purpose of this feature. Once we add
an authentication mechanism, it'll provide the former.

> 
> 
> +	if (acl_filter_xml(tmp_cib, xml_perms)) {
> +		crm_warn("Ordinary user \"%s\" doesn't have the permission for the
> whole CIB", user);
> +		tmp_cib = NULL;
> +	}
> 
> I think you're going to get complaints about how noisy this log is :-)
Indeed, it's noisy:-) I'll remove it in the next revision.

Thanks,
  Yan

-- 
Yan Gao <ygao at novell.com>
Software Engineer
China Server Team, OPS Engineering, Novell, Inc.




More information about the Pacemaker mailing list