[Pacemaker] Multi-level ACLs for the CIB

[Dejan Muhamedagic]

On Thu, Mar 18, 2010 at 02:00:04PM +0100, 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?

Yes, in particular because we can then keep the binary
compatibility.

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

Wow! AFAIK, Darwin is a clone of some BSD (FreeBSD?). uid/gid is
sort of basic, but I guess that the development is always lagging
a bit.

> Solaris will probably also have issues.

Solaris. Seems like people can't compile cluster-glue on that.
Nobody knows why.

Cheers,

Dejan


> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker