multipassd fails when sudo group does not exist

[bboozzoo]

I've installed multipass on Arch (either using --beta or --edge), multipassd exited with error:

maciek@galeon:/snap/multipass/current systemctl status snap.multipass.multipassd.service
● snap.multipass.multipassd.service - Service for snap application multipass.multipassd
   Loaded: loaded (/etc/systemd/system/snap.multipass.multipassd.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2018-10-24 10:33:49 CEST; 17min ago
  Process: 7200 ExecStart=/usr/bin/snap run multipass.multipassd (code=exited, status=1/FAILURE)
 Main PID: 7200 (code=exited, status=1/FAILURE)

paź 24 10:33:49 galeon systemd[1]: snap.multipass.multipassd.service: Service RestartSec=100ms expired, scheduling restart.
paź 24 10:33:49 galeon systemd[1]: snap.multipass.multipassd.service: Scheduled restart job, restart counter is at 5.
paź 24 10:33:49 galeon systemd[1]: Stopped Service for snap application multipass.multipassd.
paź 24 10:33:49 galeon systemd[1]: snap.multipass.multipassd.service: Start request repeated too quickly.
paź 24 10:33:49 galeon systemd[1]: snap.multipass.multipassd.service: Failed with result 'exit-code'.
paź 24 10:33:49 galeon systemd[1]: Failed to start Service for snap application multipass.multipassd.

The relevant piece of log is:

paź 24 10:08:16 galeon multipass.multipassd[4148]: [warning] [Qt] "No such interface “org.freedesktop.DBus.Properties” on object at path /org/freedesktop/NetworkManager/ActiveConnection/4"
paź 24 10:08:16 galeon multipass.multipassd[4148]: [error] [daemon] Could not determine group id for 'sudo'.
paź 24 10:08:16 galeon systemd[1]: snap.multipass.multipassd.service: Main process exited, code=exited, status=1/FAILURE

Apparently there is an assumption that sudo group must be present in the system: https://github.com/CanonicalLtd/multipass/blob/6b83f4073a45b19ca5594f5524e98ebe2434d507/src/daemon/daemon_main.cpp#L52-L72 which may not always be the case. For instance Arch does not have a sudo group. I checked with Fedora 28 cloud image, same thing there, no sudo group. Given that multipass is used by snapcraft to enabled building snaps on non Ubuntu systems, this may cause problems down the road.

Perhaps it would be best to leave the gorup ownership as root:root when there's no sudo available. Alternatively, since it's a classic snap, maybe you could try to add a multipass group in the install hook and use that for ownership.

[Saviq]

Yeah we don't want it to be classic for long. But maybe we should try a bunch of known groups and actually make it configurable via snap set to determine which group should be allowed to access.

[townsend2010]

I don't think making the multipass socket's group root is a good idea since you would have to add the root group for your user. I found that adm is used in both Arch and Fedora, so I'll check for that if sudo fails. I guess I will leave root as a last resort fallback...

Lastly, there will be a snap set for overriding any of the groups we look for.

[Saviq]

Feels like an install hook could find a fitting group and snapctl set it. This way multipassd gets told which group to use rather than trying to come up with it itself.

[townsend2010]

@Saviq,

Well, that would work for snap installs only, but when building and running from source, that won't work. It seems to me that we would still need the logic in multipassd for trying to find a usable group.

[Saviq]

@townsend2010 it's customary for services to just expose --user, --group options. If someone wants to package Multipass in another way, they'll likely know what group to use.

[townsend2010]

@Saviq,

Ok...I guess as a workaround for the issue I outlined above, we can set this as an env var like we do the for the particular backend driver and then in my development where I run the binary from built source, I'll just export the env var value.

For example, set the particular configuration key like:
$ snap set multipass socket.group=adm
And then the launch-multipassd wrapper will do something like:
MULTIPASS_SOCKET_GROUP="$(snapctl get socket.group)"
export MULTIPASS_SOCKET_GROUP
and then the daemon code will read that env var.

And when I run multipassd by hand, I can just export that env var to what I want. And then for the snap scenario, it will do as you suggest and find a suitable group for the socket.

How does that sound?

[Saviq]

Sure, env vars are good, too. I suppose long-term for each (most?) option multipass{,d} takes we should support both an env var and a command-line arg.

FWIW for development you could very well just run sudo multipass launch, but I get it why that might get annoying.

[bboozzoo]

Thanks for the fix!