On Fri, Jan 24, 2014 at 11:38 PM, roger peppe <[email protected]>wrote:
> On 24 January 2014 01:14, Andrew Wilkins <[email protected]> > wrote: > > I removed this bits that chown to the user from the local provider. I > can't, > > unfortunately, easily remove the only other remaining part: chowning the > > ~/.juju/ssh dir and keys. Suggestions welcome. > > There's also a Chown in environs/configstore that I'd very much like to > see go. > Thanks, I missed that one. > Could you expand on why it's hard to avoid chowning the ~/.juju/ssh dir > for someone that's not that familiar with this area? > > AFAICS the writeAuthorizedKeys function that creates the directory > is called by AddKeys, which is called directly from cmd/juju, which > will be running as the correct user. What am I missing? > writeAuthorisedKeys is not the problem, it's utils/ssh.LoadClientKeys that causes grief. This function will create ~/.juju/ssh and a key pair inside it if they don't exist. This function is called by juju.InitJujuHome, so very early on in the process. Doing it in InitJujuHome felt dirty, but I couldn't think of a better place at the time. More on this in a moment... When I encountered this problem, I wondered whether we could just prevent root from executing the CLI at all (by erroring out, not by any OS mechanism). This won't work with the local provider as it is, as Destroy must be run as root. Destroy calls back into the CLI via sudo. This could be changed, at the cost of making destruction more complicated. On reflection, after you mentioned configstore, I'm thinking that perhaps LoadClientKeys could be called in environs.ConfigForName (or nearby), with a sync.Once. We could then disallow preparing an environment as the root user, which covers both the configstore case and the LoadClientKeys one. What do you think about that option? Cheers, Andrew
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
