Comment 3 for bug 1844498

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.