On Thu, Mar 18, 2010 at 02:00:04PM +0100, Andrew Beekhof wrote: > On Thu, Mar 18, 2010 at 12:29 PM, Dejan Muhamedagic <deja...@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 <y...@novell.com> wrote: > >> > > >> > > >> > On 03/18/10 17:11, Andrew Beekhof wrote: > >> >> On Thu, Mar 18, 2010 at 9:53 AM, Yan Gao <y...@novell.com> wrote: > >> >>> On 03/18/10 16:33, Andrew Beekhof wrote: > >> >>>> On Wed, Mar 17, 2010 at 11:12 AM, Yan Gao <y...@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 <y...@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 <y...@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@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker _______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
