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. 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. 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? Regards, Yan -- Yan Gao <y...@novell.com> Software Engineer China Server Team, OPS Engineering, Novell, Inc. _______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
