[Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

On 03/18/10 18:30, Andrew Beekhof wrote:
> 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.

An user logs into the system shell, that means he already passed the PAM
authentication. He doesn't need/want to go through the PAM
authentication again from his point of view, unless he wants to run a
program as other identity.

While letting remote accesses go through the PAM authentication once is
not excessive.

Considering another "remote" case:
An user runs the client which is resident on the server machine via ssh.
He always needs to pass the PAM authentication once, although that would
be done by sshd instead of cib.

Isn't it reasonable there's some different for remote ones? Because they
are remote.:-)

> 
>> 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.
As least it's not a usual case. Why don't they log into the system shell
as the different identities first? :P

> 
>>
>> 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.
As implemented in the ipcsocket library of cluster-glue, there are ways
for almost all kinds of Unix system to identify the peer's uid on the
other side of a socket.

> 
> 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.
Agreed. I'll investigate the corosync's ipc mechanism. Hope it could be
ready once we decide to switch to that.

Thanks for your comments!

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