[Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

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.

> 
>>> Just make sure connections will still work on systems that don't
>>> support uid/gid.
>>
>> Eh? Which systems? I think that uid/gid are posix something.
> 
> I know Darwin only recently got pid, so it wouldn't surprise me much
> if uid/gid weren't there (or weren't hooked up).
> Solaris will probably also have issues.
> 

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