[Bug 919736] [NEW] Mounting a loop device causes the wrong loop device to be mounted.

Jon Brase 919736 at bugs.launchpad.net
Sat Jan 21 17:31:19 UTC 2012


Public bug reported:

Ubuntu 10.04.3 LTS
util-linux 2.17.2-0ubuntu1.10.04.2

There may be other packages involved in this bug than util-linux: This
bug has only affected me for a few days, whereas Synaptic reports the
last update to util-linux / mount to have been about a year ago (January
20th 2011).

After setting up a loop device with losetup, mounting that loop device
will cause the next available loop device to be mounted instead of the
designated loop device. If the loop devices are listed in fstab, this
will trigger bug 726283 when an unprivileged user attempts to unmount
them.

For example, with an fstab containing the following lines:

/dev/loop0	/mnt/loop0	auto	loop,user,noauto	0	0
/dev/loop1	/mnt/loop1	auto	loop,user,noauto	0	0
/dev/loop2	/mnt/loop2	auto	loop,user,noauto	0	0
/dev/loop3	/mnt/loop3	auto	loop,user,noauto	0	0
/dev/loop4	/mnt/loop4	auto	loop,user,noauto	0	0
/dev/loop5	/mnt/loop5	auto	loop,user,noauto	0	0


And the following commands given:

losetup /dev/loop0 image0.img
losetup /dev/loop1 image1.img
mount /dev/loop0
mount /dev/loop1


The following lines will be produced in /etc/mtab:

/dev/loop2 /mnt/loop0 iso9660 rw,noexec,nosuid,nodev,user=username 0 0
/dev/loop3 /mnt/loop1 iso9660 rw,noexec,nosuid,nodev,user=username 0 0


And losetup -f will produce the following:

/dev/loop4


Attempting to umount /dev/loop0 or /dev/loop1 will produce:

umount: /dev/loop[loop device number we attempted to umount] is not
mounted (according to mtab)


And attempting to umount /dev/loop2 or /dev/loop3 as an unprivileged user will trigger bug 726283, as /etc/fstab and /etc/mtab are inconsistent with each other as to which loop devices are associated with which directories.

In short: 
Expected result: The commands given above should result in the following mtab lines and losetup -f output:

mtab:
/dev/loop0 /mnt/loop0 iso9660 rw,noexec,nosuid,nodev,user=username 0 0
/dev/loop1 /mnt/loop1 iso9660 rw,noexec,nosuid,nodev,user=username 0 0

losetup -f:
/dev/loop2

Actual result: The commands given above result in the following mtab
lines and losetup -f output:

mtab:
/dev/loop2 /mnt/loop0 iso9660 rw,noexec,nosuid,nodev,user=username 0 0
/dev/loop3 /mnt/loop1 iso9660 rw,noexec,nosuid,nodev,user=username 0 0

losetup -f:
/dev/loop4

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: mount 2.17.2-0ubuntu1.10.04.2
ProcVersionSignature: Ubuntu 2.6.32-38.83-generic 2.6.32.52+drm33.21
Uname: Linux 2.6.32-38-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Sat Jan 21 10:40:28 2012
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/zsh
SourcePackage: util-linux

** Affects: util-linux (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug lucid

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

Title:
  Mounting a loop device causes the wrong loop device to be mounted.

Status in “util-linux” package in Ubuntu:
  New

Bug description:
  Ubuntu 10.04.3 LTS
  util-linux 2.17.2-0ubuntu1.10.04.2

  There may be other packages involved in this bug than util-linux: This
  bug has only affected me for a few days, whereas Synaptic reports the
  last update to util-linux / mount to have been about a year ago
  (January 20th 2011).

  After setting up a loop device with losetup, mounting that loop device
  will cause the next available loop device to be mounted instead of the
  designated loop device. If the loop devices are listed in fstab, this
  will trigger bug 726283 when an unprivileged user attempts to unmount
  them.

  For example, with an fstab containing the following lines:

  /dev/loop0	/mnt/loop0	auto	loop,user,noauto	0	0
  /dev/loop1	/mnt/loop1	auto	loop,user,noauto	0	0
  /dev/loop2	/mnt/loop2	auto	loop,user,noauto	0	0
  /dev/loop3	/mnt/loop3	auto	loop,user,noauto	0	0
  /dev/loop4	/mnt/loop4	auto	loop,user,noauto	0	0
  /dev/loop5	/mnt/loop5	auto	loop,user,noauto	0	0

  
  And the following commands given:

  losetup /dev/loop0 image0.img
  losetup /dev/loop1 image1.img
  mount /dev/loop0
  mount /dev/loop1

  
  The following lines will be produced in /etc/mtab:

  /dev/loop2 /mnt/loop0 iso9660 rw,noexec,nosuid,nodev,user=username 0 0
  /dev/loop3 /mnt/loop1 iso9660 rw,noexec,nosuid,nodev,user=username 0 0

  
  And losetup -f will produce the following:

  /dev/loop4

  
  Attempting to umount /dev/loop0 or /dev/loop1 will produce:

  umount: /dev/loop[loop device number we attempted to umount] is not
  mounted (according to mtab)

  
  And attempting to umount /dev/loop2 or /dev/loop3 as an unprivileged user will trigger bug 726283, as /etc/fstab and /etc/mtab are inconsistent with each other as to which loop devices are associated with which directories.

  In short: 
  Expected result: The commands given above should result in the following mtab lines and losetup -f output:

  mtab:
  /dev/loop0 /mnt/loop0 iso9660 rw,noexec,nosuid,nodev,user=username 0 0
  /dev/loop1 /mnt/loop1 iso9660 rw,noexec,nosuid,nodev,user=username 0 0

  losetup -f:
  /dev/loop2

  Actual result: The commands given above result in the following mtab
  lines and losetup -f output:

  mtab:
  /dev/loop2 /mnt/loop0 iso9660 rw,noexec,nosuid,nodev,user=username 0 0
  /dev/loop3 /mnt/loop1 iso9660 rw,noexec,nosuid,nodev,user=username 0 0

  losetup -f:
  /dev/loop4

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: mount 2.17.2-0ubuntu1.10.04.2
  ProcVersionSignature: Ubuntu 2.6.32-38.83-generic 2.6.32.52+drm33.21
  Uname: Linux 2.6.32-38-generic x86_64
  NonfreeKernelModules: nvidia
  Architecture: amd64
  Date: Sat Jan 21 10:40:28 2012
  ProcEnviron:
   LANGUAGE=en_US:en
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/zsh
  SourcePackage: util-linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/919736/+subscriptions




More information about the foundations-bugs mailing list