On 03/18/10 22:54, Yan Gao wrote: > On 03/18/10 21:00, 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? > OK, I'll do that. lrm also adopts the socket mechanism in the ipcsocket library, which previously only supported checking if a client is in the specified white list. That's why I improved the library to make the function caller know which specific user the peer is.
An interesting thing is there's getuid() in the liblrm client library. When a client registers to lrmd, it tells lrmd its id. The debug log of lrmd depends on that info. 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
