[Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

On 03/18/10 17:11, Andrew Beekhof wrote:
> On Thu, Mar 18, 2010 at 9:53 AM, Yan Gao <ygao at novell.com> wrote:
>> On 03/18/10 16:33, Andrew Beekhof wrote:
>>> On Wed, Mar 17, 2010 at 11:12 AM, Yan Gao <ygao at novell.com> wrote:
>>>> Hi Andrew,
>>>>
>>>> On 02/23/10 17:23, Yan Gao wrote:
>>>>> On 02/23/10 04:10, Andrew Beekhof wrote:
>>>>>> On Mon, Feb 22, 2010 at 8:58 AM, Yan Gao <ygao at novell.com> wrote:
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>> On 02/08/10 17:48, Andrew Beekhof wrote:
>>>>>>>> On Thu, Feb 4, 2010 at 5:24 PM, Yan Gao <ygao at novell.com> wrote:
>>>>>>>>>> And put exclusions for things like passwords before  the read for the whole cib?
>>>>>>>>> Yes. We should specify any "deny" and "write" objects before it.
>>>>>>>>
>>>>>>>> I like the syntax now, but my original concern (that all the
>>>>>>>> validation occurs in the client library) remains... so this still
>>>>>>>> isn't providing any real security.
>>>>>>> Right. If it's impossible for cib to run as root,
>>>>>>
>>>>>> If you need root for this, I think we can allow that change for 1.1.
>>>>>>
>>>>> Great! So PAM is still preferred. Anyway, I'll have a dig at different
>>>>> ways. I think we can make that change when the authentication is ready,
>>>>> and if it's necessary.
>>>> After investigating, I found that Unix domain sockets provide methods to
>>>> identify the user on the other side of a socket. That means we don't need
>>>> PAM to do authentication for local access, and the clients doesn't need
>>>> to prompt user to input and transfer username/password to the server.
>>>> And cib daemon still can run as "hacluster".
>>>>
>>>> I've improved the ipcsocket library of cluster-glue to record user's identity
>>>> info for cib to use.
>>>
>>> Looks good, but what about remote connections?
>>>
>> A remote access still needs to prompt user to input the password and go through
>> the PAM authentication completely as before. Once passed, the username will be added
>> into the op_request XML for cib_common_callback_worker() to process, which is the same
>> behavior as a local access.
> 
> I'm not hugely enthusiastic about having two different authentication
> mechanisms.
Strictly speaking, this is not another authentication mechanism. The cib
just can identify the client via the socket for a local access. So
transferring password and doing authentication for this case would be to
gild the lily I think:-)


> All things considered, allowing the cib to run as root and continuing
> to use PAM seems preferable.
But an user would never want to be asked his own username/password again
and again, whenever he runs a client, while he has already logged into
the system shell.

And for the internal accesses from crmd/pengine/attrd, we would never
have a chance (or even want) to ask their password.

Besides, once we adopt this socket mechanism:
1. crm shell could just invoke other cib*/crm_* clients as the user who
it runs as. User would never need to input password for every command.

2 For mgmtd, it could just seteuid() after the front-end passes the
authentication, and then access the cib.

What do you think?

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