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.
> >>> 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. > 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
