[Bug 1332538] Re: No UID checks on rootfs updates

[Launchpad Bug Tracker]

This bug was fixed in the package livecd-rootfs - 2.245

---------------
livecd-rootfs (2.245) utopic; urgency=medium

  * Add two new hooks for Ubuntu Touch to setup sensible /etc/passwd,
    /etc/shadow, /etc/group and /etc/gshadow PRIOR to package installation
    to guarantee user/group ordering on the image and then to check for any
    unexpected change to those files. (LP: #1332538)

    Any change to either the initial set of users and groups or to the
    post-package-install set will now be fatal to the image and will require
    a manual update of the hardcoded user/group list contained in this new
    chroot_early hook.
  * Bump dependency on live-build accordingly.
  * Update the setup_user hook to also take care of gshadow.
 -- Stephane Graber <stgraber at ubuntu.com>   Mon, 22 Sep 2014 16:02:58 -0400

** Changed in: livecd-rootfs (Ubuntu)
       Status: Confirmed => Fix Released

** Changed in: live-build (Ubuntu)
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to livecd-rootfs in Ubuntu.
https://bugs.launchpad.net/bugs/1332538

Title:
  No UID checks on rootfs updates

Status in “live-build” package in Ubuntu:
  Fix Released
Status in “livecd-rootfs” package in Ubuntu:
  Fix Released

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