The solution to this problem will be implemented through live-build
hooks. Sadly the existing set of hooks doesn't quite match what we need,
so this adds a new .chroot_early hook type which runs right after
deboostrap allowing early mangling of the user/group database.
** Package changed: system-image (Ubuntu) => livecd-rootfs (Ubuntu)
** Also affects: live-build (Ubuntu)
Importance: Undecided
Status: New
** Patch added: "live-build patch"
https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1332538/+attachment/4211806/+files/live-build.diff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to system-image in Ubuntu.
https://bugs.launchpad.net/bugs/1332538
Title:
No UID checks on rootfs updates
Status in “live-build” package in Ubuntu:
New
Status in “livecd-rootfs” package in Ubuntu:
Confirmed
Bug description:
Hi,
system-image updates will currently happily deliver an updated
/etc/passwd with the list of UIDs reordered. This typically happens
when we seed new software that creates a new user upon install.
In a recent update, my /var/crash became owned by autopilot; most
likely the UID of whoopsie became the one of autopilot after the
update.
In the short-term, we could catch such UID insertions at rootfs
creation time, either before or after a rootfs hits the -proposed
channel.
In the mid-term, we need a strategy to cope with UID
additions/removals/reorderings. One way to handle this would be to post-process
UIDs by keeping a list of historical UIDs on the server side. For instance, on
system-image.u.c systems we'd do this:
- for the first image, import /etc/passwd and keep a copy on system-image.u.c
- for updated images, compare /etc/passwd with the server copy; for each new
UID, allocate a new system UIDs in the system-image.u.c master database
- remap UIDs from the rootfs tarball to the ones in the system-image.u.c
master database
For instance, whoopsie would get a system UID allocated on system-
image.u.c the first time it's used in an image, say 120, then it keep
that 120 UID for all subsequent images. If a new image comes out of
livecd-rootfs with whoopsie as UID 121, we'd remap the UIDs to UID 120
and update /etc/passwd, /var/crash and any other file accordingly.
Perhaps there's a more clever way to deal with this; ideas welcome! I
fear that if we allow for UIDs to change in the distributed rootfs, we
will have trouble updating all the user owned files, including on
removable media, unmounted filesystems, in filesystem snapshots etc.
Cheers,
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1332538/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
