Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy
HI, On Fri, 2023-12-08 at 21:36 -0800, Ross Vandegrift wrote: > On Mon, Nov 13, 2023 at 01:48:09PM +0900, Osamu Aoki wrote: > > But not for LXD since it uses different images. Image normally downloaded > > and > > used by `lxc launch ...` becomes buggy once its instance is started because > > then > > cloud-init starts system initialization with its default setting. > > Oh right, that's what I wasn't putting together. Sorry for making you repeat > yourself. > > > Here is how I get around this problem by removing toxic netdev out of > > installed > > file /etc/cloud/cloud.cfg: > > Is unusual GID numbering the only impact, or does this cause more significant > problems? I guess user code that tries to statically assign GID 1000 will > break. Yes. Although UID=1000, GID=1000 is expected it is not guaranteed. > I agree it should be fixed. In unstable it seems reasonable to change the > config. But I'm not sure I think it warrants a stable update. For stable, if you have chance to update, please consider to add README or just keep this bug open for bookworm. README should have workaround as I wrote: https://osamuaoki.github.io/en/2023/11/12/lxc-2/#configuration-of-lxd-instance (While wait and bug upstream LXD image generation code to fix it to address this issue. https://github.com/canonical/cloud-init/issues/4603#issuecomment-1827955514 For unstable, please consider to limit groups listed to ones in base-config. Regards, Osamu
Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy
On Mon, Nov 13, 2023 at 01:48:09PM +0900, Osamu Aoki wrote: > But not for LXD since it uses different images. Image normally downloaded and > used by `lxc launch ...` becomes buggy once its instance is started because > then > cloud-init starts system initialization with its default setting. Oh right, that's what I wasn't putting together. Sorry for making you repeat yourself. > Here is how I get around this problem by removing toxic netdev out of > installed > file /etc/cloud/cloud.cfg: Is unusual GID numbering the only impact, or does this cause more significant problems? I guess user code that tries to statically assign GID 1000 will break. I agree it should be fixed. In unstable it seems reasonable to change the config. But I'm not sure I think it warrants a stable update. Ross
Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy
Hi, Not quite. On Sun, 2023-11-12 at 07:47 -0800, Ross Vandegrift wrote: > On Sat, Nov 11, 2023 at 09:46:51PM +0900, Osamu Aoki wrote: > > Package: cloud-init > > Version: 22.4.2-1 > > Severity: normal > > > > ## Background: > > > > The problem and possible root cause fix are reported on upstream github > > issue: https://github.com/canonical/cloud-init/issues/4603 > > > > ## Issue: > > I noticed instance generated from Debian bookworm cloud image on > > linuxcontainer.org had odd GID=1000 for netdev. Since netdev should be a > > system group, this situation violates Debian policy. > > Hi Osamu, > > As Shengjing Zhu mentioned in [1], this issue was fixed in #1038691. Is that > incorrect? This #1038691 is for Package: cloud.debian.org . As I understand, the bug in cloud-init is worked around and only the resulting image for cloud.debian.org is fixed via the image building code. But not for LXD since it uses different images. Image normally downloaded and used by `lxc launch ...` becomes buggy once its instance is started because then cloud-init starts system initialization with its default setting. Of course, we can avoid this situation by fixing image manually by modifying its default setting. Here is how I get around this problem by removing toxic netdev out of installed file /etc/cloud/cloud.cfg: ``` $ cd path/to $ lxc init images:debian/bookworm/cloud dbc0 $ lxc file pull dbc0/etc/cloud/cloud.cfg . $ sed -i -e 's/ netdev,//' cloud.cfg $ lxc file push cloud.cfg dbc0/etc/cloud/ $ lxc publish dbc0 --alias dbc Instance published with fingerprint: 379e858cc15808dbdf6a27a028a8b0098213656c0b4565bbc1b64b90b61d9dbd $ lxc start dbc0 $ lxc launch dbc dbc1 ``` Osamu > [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055700#25
Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy
On Sat, Nov 11, 2023 at 09:46:51PM +0900, Osamu Aoki wrote: > Package: cloud-init > Version: 22.4.2-1 > Severity: normal > > ## Background: > > The problem and possible root cause fix are reported on upstream github > issue: https://github.com/canonical/cloud-init/issues/4603 > > ## Issue: > I noticed instance generated from Debian bookworm cloud image on > linuxcontainer.org had odd GID=1000 for netdev. Since netdev should be a > system group, this situation violates Debian policy. Hi Osamu, As Shengjing Zhu mentioned in [1], this issue was fixed in #1038691. Is that incorrect? Ross [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055700#25
Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy
Package: cloud-init Version: 22.4.2-1 Severity: normal ## Background: The problem and possible root cause fix are reported on upstream github issue: https://github.com/canonical/cloud-init/issues/4603 ## Issue: I noticed instance generated from Debian bookworm cloud image on linuxcontainer.org had odd GID=1000 for netdev. Since netdev should be a system group, this situation violates Debian policy. Basically, cloud-init has a bug of creating system group starting from GID=1000 if it sees some group name listed in groups-list and missing on the system's /etc/group. ## What am I asking to Debian packagers The root cause fix takes long time in upstream. There should be some least invasive workaround to avoid this issue on most use cases simply by updating debian/cloud.cfg file. I suggest to drop "netdev" from `debian/cloud.cfg` as the least invasive minimal change. This should be done on both on stable (now) and unstable (unless upstream fixes the root cause). ## Technical consideration. This debian/cloud.cfg is installed by override_dh_installinit target in debian/rules . I compaired this against upstream config/cloud.cfg.tmpl. It looks like this has modified upstream generated cloud.cfg which sharies its contents with Ubuntu. I see "[Uu]buntu" swapped with "[Dd]ebian" in cloud.cfg. Besides these cosmetic changes, Debian packaging already made interesting change in it. Let's look at groups in cloud.cfg. upstream: adm, audio, cdrom, dialout, dip, floppy, lxd, netdev, plugdev, sudo, video debian: adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video I don't know how these are chosen mostly for Ubuntu by upstream but Debian packager made decision to drop "lxd" here. Minimal Debian system has its system group defined in base-passwd package. So "adm, audio, cdrom, dialout, dip, floppy, plugdev, sudo, video" are guranteed to exist. Debian package should drop not only "lxd" but also "netdev". I don't think removing `netdev` cause much problem. As you know, `netdev` is for `/dev/wfkill` and wpsupplicant and similar packages. If anyone decides to add these packages to the root image, it get generated properly by postinst. Of course, adding `netdev` group to the primary user account `debian` is needed if the user wishes. That's something to be documented. We must keep Debian system compliant to Debian policy. Debian Policy https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes 100-999: Dynamically allocated system users and groups. Packages which need a user or group, but can have this user or group allocated dynamically and differently on each system, should use adduser --system to create the group and/or user. adduser will check for the existence of the user or group, and if necessary choose an unused id based on the ranges specified in adduser.conf. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cloud-init depends on: ii eject 2.38.1-5+b1 ii fdisk 2.38.1-5+b1 ii gdisk 1.0.9-2.1 ii isc-dhcp-client4.4.3-P1-2 ii locales2.36-9+deb12u3 ii lsb-base 11.6 ii lsb-release12.0-1 ii procps 2:4.0.2-3 ii python33.11.2-1+b1 ii python3-configobj 5.0.8-1 ii python3-jinja2 3.1.2-1 ii python3-jsonpatch 1.32-2 ii python3-jsonschema 4.10.3-1 ii python3-netifaces 0.11.0-2+b1 ii python3-oauthlib 3.2.2-1 ii python3-requests 2.28.1+dfsg-1 ii python3-serial 3.5-1.1 ii python3-yaml 6.0-3+b2 ii sysvinit-utils [lsb-base] 3.06-4 ii util-linux 2.38.1-5+b1 Versions of packages cloud-init recommends: ii cloud-guest-utils 0.33-1 ii eatmydata 130-2 ii sudo 1.9.13p3-1+deb12u1 Versions of packages cloud-init suggests: ii btrfs-progs 6.2-1 ii e2fsprogs1.47.0-2 ii xfsprogs 6.1.0-1 -- no debconf information
