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

[Dimitri John Ledkov]

This has now added
lxd:x:101:

Into ubuntu-base tarballs http://cdimage.ubuntu.com/ubuntu-
base/daily/pending/ which is a bit problematic.

Was that intended?

core20 snap builds started to fail now, as it installs a few more
packages on top of base, and expects to maintain stable gids

Currently the below gids were already in use

netdev:x:101:
crontab:x:102:
messagebus:x:103:
snappypkg:x:104:
ssh:x:105:
systemd-journal:x:106:
systemd-timesync:x:108:
systemd-network:x:109:
systemd-resolve:x:110:
systemd-bus-proxy:x:111:
kvm:x:112:
docker:x:113:
syslog:x:114:
pkcs11:x:115:
tss:x:116:
input:x:107:
render:x:117:

Imho ubuntu-base should not contain any gids that are not declared
statically by base-files.

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