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

[Oliver Grawert]

note that the build scripts for core do have an md5sum check to detect changes to /etc/passwd|group|shadow because this file is orignally readonly.
dirs created with specific UIDs/GIDs by package postinist scripts that get copied into the writable area of the rootfs during first boot would fail to be owned by the daemon users the packages set up for them during a core update... 

adding a new entry to one of the readonly password db files is fine but
requires changes in livecd-rootfs and an update of the expected md5sum
...

additionally to the above, since /etc/group is readonly, you can not add
users to the lxd group if you add lxd there so unprivileged containers
on core will become impossible, the GID of lxd should be transferred
into /var/lib/extrausers/group to make it possible to add a local system
user to this group.

-- 
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:
  Invalid
Status in livecd-rootfs package in Ubuntu:
  Fix Released
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