[Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

On 03/18/10 22:54, Yan Gao wrote:
> On 03/18/10 21:00, Andrew Beekhof wrote:
>> On Thu, Mar 18, 2010 at 12:29 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
>>> Hi,
>>>
>>> On Thu, Mar 18, 2010 at 11:30:10AM +0100, 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.
>>>>
>>>>> 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.
>>>
>>> I'd agree. I think that we're already doing some IPC based
>>> authentication with glib2 (when connecting to lrmd). Perhaps that
>>> could've been used here too?
>>
>> Might be worth looking into... Yan?
> OK, I'll do that.
lrm also adopts the socket mechanism in the ipcsocket library, which
previously only supported checking if a client is in the specified white
list. That's why I improved the library to make the function caller know
which specific user the peer is.

An interesting thing is there's getuid() in the liblrm client library.
When a client registers to lrmd, it tells lrmd its id. The debug log of
lrmd depends on that info.

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