[Pacemaker] Multi-level ACLs for the CIB

[Andrew Beekhof]

On Thu, Mar 18, 2010 at 11:10 AM, Yan Gao <ygao at novell.com> wrote:
>
>
> 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.

Thats what I mean, we're using one type of authentication mechanism
for remote users and a different type for local ones.

> 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.

Good point.
Would users ever want to log in using different credentials? Perhaps not.

>
> 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?

Well I would like to pick just one mechanism, but you raise some
compelling reasons to use socket based authentication.
Just make sure connections will still work on systems that don't
support uid/gid.

Also, be aware that at some point in the future we will probably
switch to corosync's ipc mechanism.
I checked and the same type of authentication should be possible, but
it may be worth starting to get it added sooner rather than later.