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.
** Also affects: snapd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1844498
Title:
18.10+ cloud images have the LXD group as gid 1000
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1844498/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
