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

[Steve Langasek]

On Thu, Sep 26, 2019 at 05:27:22PM -0000, Michael Vogt wrote:
> I wonder if adding something to cloud.cfg that ensures there is a lxd
> group created as a system-group would be the way forward? Especially
> since we already reference this group in cloud.cfg.

For the specific case of a preseeded snap which we know should have an
associated group, I think we should handle this in livecd-rootfs and
statically create the group in the image since both are static aspects of
the image mastering.  We CAN instruct cloud-init to create this as a system
group, but the point is that this is a layering violation; we should not
have to keep the cloud.cfg and the lxd snap in sync with regards to the
properties of the groups being created.

The reason I think that there should be extensions to cloud-init for this at
all is for the case where you have a *non* preseeded package which you want
to install as part of the instance config, and you want to add your user to
the group that will be created by that package.  That could be either a deb
or a snap, doesn't matter.  I don't think it smells good to have cloud-init
creating the group in this case.

-- 
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