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