lack of installer permission validation on existing partition

Bug #224446 reported by zombiefish on 2008-04-29
8
Affects Status Importance Assigned to Milestone
partman-target (Ubuntu)
Medium
Evan
Hardy
Medium
Colin Watson

Bug Description

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) wrote :

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

Changed in ubiquity:
importance: Undecided → Medium
status: New → Triaged
assignee: nobody → evand
importance: Undecided → Medium
milestone: none → ubuntu-8.04.1
status: New → Triaged
Evan (ev) wrote :

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) wrote :

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.

Evan (ev) on 2008-05-17
Changed in ubiquity:
status: Triaged → Fix Committed
Evan (ev) on 2008-06-13
Changed in ubiquity:
milestone: ubuntu-8.04.1 → ubuntu-8.04.2
Colin Watson (cjwatson) wrote :

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

Changed in ubiquity:
status: Fix Committed → Fix Released
Colin Watson (cjwatson) wrote :

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

description: updated
Changed in partman-target:
assignee: nobody → evand
assignee: evand → kamion
Steve Langasek (vorlon) wrote :

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!

Changed in partman-target:
milestone: ubuntu-8.04.2 → none
status: Triaged → Fix Committed
Steve Langasek (vorlon) on 2008-12-15
Changed in partman-target:
milestone: none → ubuntu-8.04.2
Colin Watson (cjwatson) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Changed in partman-target:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers