[Pacemaker] Multi-level ACLs for the CIB

[Andrew Beekhof]

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?

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