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