[Bug 1844498] Re: 18.10+ cloud images have the LXD group as gid 1000

[Dan Watkins]

This is complicated.

The root cause, I believe, is lxd moving from a deb (which created the
lxd system group when installed during image build) to a snap (which
creates the group after/during first boot but, crucially, after cloud-
init has created users and therefore the lxd group itself).  As a
result, the expected Ubuntu experience (`ubuntu` user is in the `lxd`
system group when created) degraded.  This is another symptom of snaps
being poorly integrated into classic Ubuntu systems, I think.

My feeling is that this is really a snap-seeding-on-classic issue.  The
lxd snap should have a way of expressing "I want a lxd system group" and
the seeding process should ensure that the system is configured in a way
that won't cause these problems.  There are some changes to the seeding
process in the works, so I've added a snapd task to get input on whether
that's at all realistic to hope for.

In the absence of snapd changes, from a cloud-init perspective this
feels like an image misconfiguration to me.  lxd is a core part of the
Ubuntu Server experience that we provide[0], and not having a lxd system
group in the image was not an intentional change, but an accident
brought about by the move to a snap.

[0] IIRC, the minimal cloud images don't include lxd, so we should also
consider what the desired behaviour there should be.

> We have the suggestion that user creation should not initially create
user groups that do not exist.

Changing the default behaviour would be a non-starter for backport to
stable releases[0], but we could consider doing this with an additional
configuration option in the user specification (e.g. "create_if_missing:
False").  This wouldn't result in the `ubuntu` user being in the `lxd`
group by default, though, without additional 2-stage changes also
proposed.

Alternatively, we could allow specifying that groups should be created
as system groups (e.g. "system: True").  This would mean that the lxd
system group would exist on systems where lxd isn't seeded (such as the
minimal cloud images), which is less than ideal IMO[1].

Either of these options would require a fundamental modification of the
schema for groups[2] (and cloud-init SRUs), so should not be considered
a quick route to resolving this issue, IMO.  And, further, it's not
clear to me that they are actually _correct_ ways to resolve this.


Cheers,

Dan


[0] People could be happily relying on cloud-init to create user groups they specify for users today, and we don't want to break those people.
[1] As a security-conscious user launching a minimal cloud image and manually installing lxd later, I probably wouldn't expect any users to be able to interact with lxd by default.
[2] The current schema doesn't have support for any options for groups; they're just strings.  Furthermore, dicts already have specific meaning in that code (group name -> list of group members).  So we would need to do the investigation into the schema changes and the work to add support for options to groups, in addition to support for the specific options we want.

** Also affects: snapd (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to livecd-rootfs in Ubuntu.
https://bugs.launchpad.net/bugs/1844498

Title:
  18.10+ cloud images have the LXD group as gid 1000

Status in cloud-images:
  New
Status in cloud-init package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  New

Bug description:
  The LXD group is meant to be a system group (< 1000).
  The logic in our deb and snap packages is to create it with --system.

  However, we've recently had a report that on cosmic and higher, the LXD group is at gid 1000.
  The lxd user itself isn't affected and is getting a system uid as expected.

  The image itself doesn't contain that group in /etc/group so it
  appears to be created on first boot.

  Some investigation made me think of this part of /etc/cloud/cloud.cfg:
     default_user:
       name: ubuntu
       lock_passwd: True
       gecos: Ubuntu
       groups: [adm, audio, cdrom, dialout, dip, floppy, lxd, netdev, plugdev, sudo, video]
       sudo: ["ALL=(ALL) NOPASSWD:ALL"]
       shell: /bin/bash

  As the group will only exist when the snap gets installed, it seems
  possible that cloud-init would be the one automatically creating the
  group in such case, wrongly creating it as a user group rather than a
  system group.

  The easiest way out of this would be to either have the image build
  process or cloud-init itself create it as a system group ahead of user
  creation.

     groupadd --system lxd

  This would then have cloud-init use the system group for the default
  user and the LXD snap will happily use the existing group too.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1844498/+subscriptions