Package: mount Version: 2.12r-19 Hi, Today I discovered (what I believe is) a problem with mount: you can successfully loop-mount a file multiple times, even with the mount point the same. This is not very bad if the filesystem on that file is read-only (ie iso9660), but this can cause data loss on a rw filesystem. Kernel version: 2.6.18-4-k7 libc6 version: 2.3.6.ds1-13 coreutils version: 5.97-5.3 Debian version: Lenny Below is a copy of a session where I successfully reproduced the bug: $ su Password: jdebian:/home/jason# cd /tmp jdebian:/tmp# mkdir foo jdebian:/tmp# cd foo jdebian:/tmp/foo# dd if=/dev/zero of=bar.img bs=1024 count=8192 8192+0 records in 8192+0 records out 8388608 bytes (8.4 MB) copied, 0.114386 seconds, 73.3 MB/s jdebian:/tmp/foo# losetup /dev/loop2 bar.img jdebian:/tmp/foo# mkfs.ext2 /dev/loop2 mke2fs 1.40-WIP (14-Nov-2006) Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 2048 inodes, 8192 blocks 409 blocks (4.99%) reserved for the super user First data block=1 Maximum filesystem blocks=8388608 1 block group 8192 blocks per group, 8192 fragments per group 2048 inodes per group
Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 29 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. jdebian:/tmp/foo# losetup -d /dev/loop2 jdebian:/tmp/foo# mount bar.img /mnt -t ext2 -o loop jdebian:/tmp/foo# echo qwerty >/mnt/baz jdebian:/tmp/foo# mount bar.img /mnt -t ext2 -o loop jdebian:/tmp/foo# mkdir /mnt/qux jdebian:/tmp/foo# echo uiop >/mnt/qux/xyzzy jdebian:/tmp/foo# mount /dev/hda7 on / type xfs (rw) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) none on /sys/fs/fuse/connections type fusectl (rw) /dev/hda8 on /boot type ext3 (rw) /dev/hda12 on /home type ext3 (rw) /dev/hda10 on /tmp type xfs (rw) /dev/hda11 on /var type ext3 (rw) /dev/hda1 on /wd/c type vfat (rw,nosuid,nodev,uid=1000,gid=6) /dev/hda2 on /wd/m type vfat (rw,nosuid,nodev,uid=1000,gid=6) /dev/hdb1 on /wd/z type vfat (rw,nosuid,nodev,uid=1000,gid=6) /dev/hdb6 on /wd/f type fuse (rw,nosuid,nodev,noatime,allow_other) /dev/hdb7 on /wd/x type fuse (rw,nosuid,nodev,noatime,allow_other) /dev/hda5 on /wd/l type fuse (rw,nosuid,nodev,noatime,allow_other) /dev/hda6 on /wd/r type fuse (ro,nosuid,nodev,noatime,allow_other) /dev/hdb5 on /wd/.s type ntfs (rw) /etc/read-only/image.sfs on /etc/read-only/mnt type squashfs (ro,loop=/dev/loop0) /dev/sda1 on /media/usb type vfat (rw,noexec,nosuid,nodev,user=jason) /tmp/foo/bar.img on /mnt type ext2 (rw,loop=/dev/loop2) /tmp/foo/bar.img on /mnt type ext2 (rw,loop=/dev/loop3) jdebian:/tmp/foo# umount /mnt jdebian:/tmp/foo# ls /mnt baz lost+found jdebian:/tmp/foo# mount bar.img /mnt -t ext2 -o loop jdebian:/tmp/foo# ls /mnt lost+found qux jdebian:/tmp/foo# umount /mnt jdebian:/tmp/foo# umount /mnt jdebian:/tmp/foo# fsck.ext2 -f bar.img e2fsck 1.40-WIP (14-Nov-2006) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Inode 2 ref count is 3, should be 4. Fix<y>? yes Pass 5: Checking group summary information Free blocks count wrong for group #0 (7885, counted=7884). Fix<y>? yes Free blocks count wrong (7885, counted=7884). Fix<y>? yes Free inodes count wrong for group #0 (2036, counted=2035). Fix<y>? yes Directories count wrong for group #0 (2, counted=3). Fix<y>? yes Free inodes count wrong (2036, counted=2035). Fix<y>? yes bar.img: ***** FILE SYSTEM WAS MODIFIED ***** bar.img: 13/2048 files (7.7% non-contiguous), 308/8192 blocks Although I don't believe something this obvious would occur, a user might forget that they had already mounted a file (as this also works if the thing is in fstab) and mount it again. Thanks, Jason __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
