18.10+ cloud images have the LXD group as gid 1000
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-images |
New
|
Undecided
|
Unassigned | ||
snapd |
Incomplete
|
Undecided
|
Unassigned | ||
cloud-init (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
livecd-rootfs (Ubuntu) |
Fix Released
|
Undecided
|
Michael Hudson-Doyle | ||
snapd (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
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/
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.
Related branches
- Adam Conrad (community): Approve
-
Diff: 37 lines (+18/-0)2 files modifieddebian/changelog (+6/-0)
live-build/auto/config (+12/-0)
tags: | added: id-5d84bb1ca26b0679a708dc40 |
tags: | added: id-5d9f086c55aa263ba7e2f5e5 |
I have added two other packages to this bug.
livecd-rootfs - For the ubuntu-server and ubuntu-cpc projects a chroot hook should be added to create the lxd system group.
cloud-init - We have the suggestion that user creation should not initially create user groups that do not exist. You may consider adding a second pass in a final cloud-init module which would add groups for the default user which did not exist during the first pass (or create them if they still do not exist; and adding a mechanism for identifying system groups would be a good enhancement). This 2-stage approach would allow packages and snaps that get installed during boot (after cloud-init creates the default user) to create their own groups and manage them while ensuring the default user does get added to these.