The group of dbus-daemon-launch-helper is wrong

Still can reproduce the issue with latest rootfs.

$ ls -n usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-- 1 0 108 51344 Jun 12 2020 usr/lib/dbus-1.0/dbus-daemon-launch-helper
$ grep -r -e "108" etc/group
kvm:x:108:

---
[1] https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-root.tar.xz

Still can reproduce the issue with latest rootfs.

Jammy:
$ ls -n usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-- 1 0 106 35112 Sep 9 21:45 usr/lib/dbus-1.0/dbus-daemon-launch-helper
$ grep -r -e "106" etc/group
systemd-timesync:x:106:

Focal:
$ ls -n usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-- 1 0 107 51344 Jun 12 2020 usr/lib/dbus-1.0/dbus-daemon-launch-helper
$ grep -r -e "107" etc/group
input:x:107:

---
https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-root.tar.xz
https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-root.tar.xz

There is nothing in the CPC image build code that changes ownership related to this package. I'll add dbus, as this looks like it could be a packaging type issue?

I brought this up among my colleagues in the security team and we kicked around a few ideas.

It seems likely that the host /etc/group doesn't match the rootfs /etc/group file. tar will write both uid/gid as well as username/groupname to tarballs, and the extraction process will use the names where it can, and will use the numbers where it can't.

https://www.gnu.org/software/tar/manual/html_node/Standard.html

"The magic field indicates that this archive was output in the P1003 archive format. If this field contains TMAGIC, the uname and gname fields will contain the ASCII representation of the owner and group of the file respectively. If found, the user and group IDs are used rather than the values in the uid and gid fields."

The guesses on ways to handle this:

- use --numeric-owner when creating the tarballs to skip the text names
- use --group-map when creating the tarballs to map the rootfs names/numbers to host names/numbers
- set up a new usernamespace, new mount namespace, and bindmount the rootfs /etc/passwd and /etc/group into the new namespace, so the tar process's getpwent, getgrent calls will reflect the new root filesystem.
- run the tar from a chroot within the rootfs

I think these are in rough preference order, but there might be huge consequences to omitting the text names from tarballs that I am completely unaware of. That's the largest change in what we produce, the --group-map and bindmount ideas are minimal changes to tools and what's produced, and the last one is probably too reliant upon the image actually having a suitable tar command.

Thanks

Hi Seth

Any updates? I tried the latest rootfs and still can reproduce the issue.

$ ls -n usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-- 1 0 106 35112 Apr 2 01:02 usr/lib/dbus-1.0/dbus-daemon-launch-helper
$ grep -r -e "106" etc/group
systemd-timesync:x:106:

---
https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-root.tar.xz