Assumes that it runs under sudo and breaks if it doesn't.

[Ian Kumlien]

Hi,

I made it use utils.install_user() since it handles the "root" case.

I don't know if i should revert back to:
    if not user_name:
        return

instead.

Author: Ian Kumlien <email address hidden>
Date: Wed Jan 21 15:19:33 2015 +0100

    drop_privileges: don't break if no sudo

    If the user didn't use sudo or f.ex. used sudo su
    to avoid rootsquash problems on homedirectories then
    SUDO_USER is not set and we'll basically break.

diff --git a/cloudinstall/multi_install.py b/cloudinstall/multi_install.py
index 2daf49c..ec90cfa 100644
--- a/cloudinstall/multi_install.py
+++ b/cloudinstall/multi_install.py
@@ -181,7 +181,8 @@ class MultiInstall(InstallBase):
         if os.geteuid() != 0:
             return

- user_name = os.getenv("SUDO_USER")
+ user_name = utils.install_user()
+
         pwnam = pwd.getpwnam(user_name)
         os.initgroups(user_name, pwnam.pw_gid)
         os.setregid(pwnam.pw_gid, pwnam.pw_gid)

[Mike McCracken (mikemc)]

Ian, thanks for looking into this. Can you explain a little further about what problems this fixes?
I'm afraid I'm not familiar with reasons to use 'sudo su' (I assume, followed by running the installer as root) instead of just 'sudo openstack-install'.

In any case, if you do use sudo su, does it make sense to drop privileges? Probably not, so I think your initial comment about just returning if SUDO_USER is not set is probably better.

However, since we've assumed that the only way this should be run is using 'sudo openstack-install', you may experience other issues, probably related to permissions problems with files created by other places that use utils.install_user and expect that to not return root.

[Ian Kumlien (pomac)]

It's very common, at least in my experience, that machines have their home directories on NFS shares. And since most companies are "legacy" to us they use NFSv3 and not v4... Due to the security implications in this, all nfs home directories are exported with all kinds of squash settings to mitigate the issue ;)

So, if you do sudo -s or sudo <binary> they will immediately complain that they can't read-from/write-to or even see the home directory... Things like maas doesn't like it - heck, it's hard to find more complex tools that do...

So it should be changed to:
if user_name is None:
    return

Do you need a new patch? ;)

Anyway, yes - I know, or you could say that i have noticed, that it's not that tested beyond the normal ubuntu parameters which is why i submitted the patches =)

I have *ALMOST* completed a install with this though, it failed while "refreshing status from juju" (i was monitoring juju as well in another terminal so that might be it) but the install is up and runing (both juju and openstack)

[Mike McCracken (mikemc)]

>
> I have *ALMOST* completed a install with this though, it failed while
> "refreshing status from juju" (i was monitoring juju as well in another
> terminal so that might be it) but the install is up and runing (both
> juju and openstack)

wrt this, please file another bug, as that should not fail. Juju supports
concurrent access to its status db.
If you can include the contents of ~/.cloud-install/commands.log in your
bug report, there should be a python backtrace in there that might help
figure out the cause

On Mon, Jan 26, 2015 at 12:42 PM, Ian Kumlien <email address hidden>
wrote:

> It's very common, at least in my experience, that machines have their
> home directories on NFS shares. And since most companies are "legacy" to
> us they use NFSv3 and not v4... Due to the security implications in
> this, all nfs home directories are exported with all kinds of squash
> settings to mitigate the issue ;)
>
> So, if you do sudo -s or sudo <binary> they will immediately complain
> that they can't read-from/write-to or even see the home directory...
> Things like maas doesn't like it - heck, it's hard to find more complex
> tools that do...
>
> So it should be changed to:
> if user_name is None:
> return
>
> Do you need a new patch? ;)
>
> Anyway, yes - I know, or you could say that i have noticed, that it's
> not that tested beyond the normal ubuntu parameters which is why i
> submitted the patches =)
>
> I have *ALMOST* completed a install with this though, it failed while
> "refreshing status from juju" (i was monitoring juju as well in another
> terminal so that might be it) but the install is up and runing (both
> juju and openstack)
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1413243
>
> Title:
> Assumes that it runs under sudo and breaks if it doesn't.
>
> Status in Ubuntu Openstack installer:
> Triaged
>
> Bug description:
> Hi,
>
> I made it use utils.install_user() since it handles the "root" case.
>
> I don't know if i should revert back to:
> if not user_name:
> return
>
> instead.
>
> Author: Ian Kumlien <email address hidden>
> Date: Wed Jan 21 15:19:33 2015 +0100
>
> drop_privileges: don't break if no sudo
>
> If the user didn't use sudo or f.ex. used sudo su
> to avoid rootsquash problems on homedirectories then
> SUDO_USER is not set and we'll basically break.
>
> diff --git a/cloudinstall/multi_install.py
> b/cloudinstall/multi_install.py
> index 2daf49c..ec90cfa 100644
> --- a/cloudinstall/multi_install.py
> +++ b/cloudinstall/multi_install.py
> @@ -181,7 +181,8 @@ class MultiInstall(InstallBase):
> if os.geteuid() != 0:
> return
>
> - user_name = os.getenv("SUDO_USER")
> + user_name = utils.install_user()
> +
> pwnam = pwd.getpwnam(user_name)
> os.initgroups(user_name, pwnam.pw_gid)
> os.setregid(pwnam.pw_gid, pwnam.pw_gid)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-installer/+bug/1413243/+subscriptions
>