[Pacemaker] Multi-level ACLs for the CIB

[Dejan Muhamedagic]

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?

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

Thanks,

Dejan

> 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.
> 
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker