lack of installer permission validation on existing partition

[zombiefish]

The installer fails to correct, or even warn about, invalid ownership or permissions on the root directory entry of the partition's filesystem(/).

Such a situation can lead to certain programs, like sudo, failing to work after installation is completed.

(This bug may also be considered a security vulnerability, but that's probably stretching it a bit far. ;))

TEST CASE: Described in:
  https://bugs.launchpad.net/ubuntu/hardy/+source/partman-target/+bug/224446/comments/2
  https://bugs.launchpad.net/ubuntu/hardy/+source/partman-target/+bug/224446/comments/3

[Colin Watson (cjwatson)]

Seems like it should be simple, and a plausible 8.04.1 candidate. (No need to warn; it could just correct the permissions.) Evan?

[Evan (ev)]

It sounds simple, though I'm not sure I understand where this is occurring. Sarah, how can I reproduce this bug? Did you elect to reuse a root partition and not format it, where said partition already had the wrong permissions on /?

[zombiefish (zombiefish)]

That's correct. I installed it on a partition on a drive I had previously used solely as a media storage drive, and the root directory entry of the filesystem was chown'd to my non-root username.

[Colin Watson (cjwatson)]

partman-target (55ubuntu1) intrepid; urgency=low

  [ Evan Dandrea ]
  * Ensure that if we clear the root partition, / is owned by root:root
    (LP: #224446).

  [ Colin Watson ]
  * Resynchronise with Debian. Remaining changes:
    - Use UUID= fstab syntax for all partitions if a UUID is available, and
      add a comment above each UUID to indicate the corresponding device at
      install time.
    - Disable automatic mounting of USB removable devices.
    - Don't use UUIDs in fstab for those device types that volumeid.postinst
      refuses to convert.
    - Mount CD-ROMs and floppies with 'exec'.
    - Use the path of the file associated with a loop device in /etc/fstab,
      rather than the filesystem's UUID or the loop device path.
    - Always set the loop option for loop devices.
    - Remove critical system files from the existing filesystem before
      installing.
    - Preserve the UID and GID of the initial user, if possible. Requires a
      patch to user-setup.
    - Mount CD-ROMs and floppies with the "utf8" option by default.

 -- Colin Watson <email address hidden> Fri, 13 Jun 2008 21:14:30 +0100

[Colin Watson (cjwatson)]

I've uploaded Evan's patch as a stable update for hardy.

[Steve Langasek (vorlon)]

Accepted into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Colin Watson (cjwatson)]

I've just uploaded ubiquity 1.8.13 to hardy-proposed, including this fix. (Prior to this, testing was only possible with alternate/server CDs.)

[Dave Morley (davmor2)]

Tested on cd 20090112.1.

Seems to be fine, I setup a /home/tester partition and then didn't format it and then on a second install changed it to / manual install. I can access all files and directories correctly and sudoing commands works as expected.

[Steve Beattie (sbeattie)]

I can also confirm this fix using the hardy daily desktop image from 20090112.1; I had a previous installation that I chowned /, /*, and /usr/* to different users, and then did a non-formatting manual installation to that image. All were corrected (include the ownership of /home, which I wasn't sure would be corrected) except for /lost+found, which retained its non-uid 0 ownership.

I also tested with different ownerships, where only the user or group had been modified, and these were addressed as well.

I think the fix is probably an improvement over the former situation, but what do others think about the /lost+found issue? (Granted, /lost+found's ownership is unlikely to get changed).

[Steve Langasek (vorlon)]

I think we can consider this fix validated in spite of the lost+found issue. I'll leave it up to Colin and Evan whether a second SRU is warranted for the lost+found permissions, but I think that's a lower-priority problem that doesn't need to block 8.04.2.

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-target - 54ubuntu7

---------------
partman-target (54ubuntu7) hardy-proposed; urgency=low

  [ Evan Dandrea ]
  * Ensure that if we clear the root partition, / is owned by root:root
    (LP: #224446).

 -- Colin Watson <email address hidden> Mon, 15 Dec 2008 13:55:25 +0000