Mechanism to create system groups

Bug #1606510 reported by Stéphane Graber on 2016-07-26
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Snappy
Undecided
Unassigned

Bug Description

LXD's main security mechanism for local users is done through group membership.

The LXD snap assumes the existence of a "lxd" group and makes the lxd unix socket owned by that group. That way only members of that group (or root) may access LXD.

snapd interfaces work great to prevent other snaps from talking to LXD, but do not help restricting access from other applications (on classic).

For the time being, the LXD snap simply assumes that the "lxd" group exists. If it doesn't the daemon will fail to start.

This bug is to track both a temporary workaround (as suggested by Mark in comments below) to just have snapd always create the "lxd" system group if it doesn't exist.

And to discuss what the right mechanism to manage groups would be moving forward.

Tags: lxd Edit Tag help
Stéphane Graber (stgraber) wrote :

So after further discussion it sounds like what we want is actually the ability to get a group created on the system.

We'd then have a "lxd" group appear when the lxd snap is installed, our unix socket would be owned by root:lxd 0660 just like it is right now with the deb version.

Snaps that connect to lxd and run as root (most of them) will be able to talk to it, anything else will need to be added to the lxd group by an admin first.

This fixes the security concern in a way which requires explicit user interaction when granting unprivileged users access to LXD.

tags: added: snapd-interface

Good idea to add a group-creation mechanism, but to do it properly will
take a bit of time. Can I suggest that we find a quick path which
assumes that snapd will autocreate that lxd group on install / update on
the host system, for now? In other words, just add that group on all
systems where it is not added, so when the snap arrives it can just use
that user? A full group-creation interface will need:

 * the snap can specify what groups it wants
 * the store sends snaps for review which ask for groups that are not
yet approved
 * the store can tell snapd which groups are approved via an assertion
 * snapd can create the group and if needed pick a different name to
avoid collisions
 * the snap when installed can discover the actual group name when it is
executed

That's a lot of wiggles to code and debug :)

A fast path would be:

 * snapd deb / rpm / pkg scripts create that group everywhere
 * lxd snap just assumes it for now

Mark

Fine with me, I'll just assume the group exists for now.

I'll still need the systemd socket activation bits I mentioned on the list so I can make use of said group and have the socket created and properly configured for use with LXD.

summary: - Interfaces for LXD
+ LXD bits

one bigger issue i see here is that we have two different systems with two different group files (actually 3 since the core snap needs to use a merge of a readonly and a readwrite db), i assume lxd running in context of the core snap will only be able to use the database of the core snap by default so we need to make sure to:

- get matching GIDs between host and core snap
  (on a debian system the snapd deb will just grab the last free GID below 1000 but snapd
   wont know if that GID is freely available in the readonly /etc/group of the
   core snap before the core snap is installed, so it is hard to block on this)

- make sure inside the core snap everything integrates fine with the libnss-extrausers setup
  (we only use it for users currently, the system groups usecase will need some testing)

description: updated
Jamie Strandboge (jdstrand) wrote :

@Mark et al, IMHO adding the 'lxd' user via packaging seems reasonable for the immediate-term solution. That is what we did in 15.04.

As an intermediate step towards the final solution, I wonder if snapd could add a new backend for interfaces to create gids (and uids) and then the lxd interface itself says "create the 'lxd' gid if it doesn't exist". In this manner, other slot-implementations that need their own interface (eg, docker) could do the same thing. This is needed for what you've layed out as the long term solution (we need a way to create these anyway) but means we don't have to keep telling packagers to update the list of users and groups and the interfaces that need it now aren't blocked on the the assertions/store work.

Oliver Grawert (ogra) wrote :

that sounds very sensible and goes even beyond docker and lxd ...after all we might have interfaces that might provide shared directories with write access between the host and the core snap where file permissions and ownership must match ...

Yes, the hard part of that will be if we want to deal with conflicts
(e.g. an existing user with a desired name).

Mark

description: updated
description: updated
summary: - LXD bits
+ Mechanism to create system groups
description: updated
Stéphane Graber (stgraber) wrote :

So I'm recycling this bug report for what we discussed the most in comments, how to get the "lxd" group on our users' system.

The current recommendation I believe is to have snapd always create it (needs to be a system group!) and then figure out a clean way to address such needs moving forward.

All the other bits that were raised in this bug have been split into separate bugs (look for the lxd tag).

tags: added: lxd
removed: snapd-interface
Greg Lutostanski (lutostag) wrote :

This is preventing me from installing the lxd snap on core-16, as there is no way to
```
sudo groupadd --system lxd
sudo usermod -G lxd -a <username>
```
as suggested by https://www.stgraber.org/2016/10/17/lxd-snap-available/, because /etc/groups is on the read-only filesystem of core-16.

I would really like to be able to run lxd on my rpi2 with core-16.

Oliver Grawert (ogra) wrote :

to add a group on core you need to use the --extrausers arg for addgroup and adduser, like:

sudo addgroup --extrausers --system lxd

sadly there seems to be some patch missing for the next step though:

ogra@pi3:~$ sudo adduser --extrausers ogra lxd
adduser: The group `lxd' does not exist.

as well as:

ogra@pi3:~$ sudo usermod -G lxd -a ogra
usermod: group 'lxd' does not exist

the second one is no surprise but the adduser behaviour is since all tools it uses internally are supposed to know about extrausers...

i have filed Bug #1647333 for this specific issue. as a quick workaround to get the group working anyway you can edit /var/lib/extrausers/group and /var/lib/extrausers/group- and add the username to the end of the lxd line.

Changed in snappy:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers