mount -o loop.... changes the udf image

[qji]

I tested an UDF iso image with mount -o loop... and I was really surprised, the mount changed the image. I am not sure what it writes to the image, probably almost nothing (mount time stamp?) but the checksum of the image is changed. It's very bad when you download something you mount it (just to test) and then you want to check the checksum of the file....

to check:

$ mkdir testdir
$ genisoimage -udf -o testimage.iso testdir/
...
$ sudo md5sum testimage.iso
92c720ac623ed697e222047b23935a0c testimage.iso
$ sudo mount -o loop testimage.iso /mnt
mount: block device /home/qji/testimage.iso is write-protected, mounting read-only < --- mount says it's a read only mount
$ md5sum testimage.iso
0bc99bab37df097c5aabff7bc6a6de68 testimage.iso < --- checksum is already changed
$ sudo umount /mnt
$ md5sum testimage.iso
0bc99bab37df097c5aabff7bc6a6de68 testimage.iso < --- umount doesn't touch the file

[qji (qji)]

My Ubuntu is an up to date 12.04 x64.

[Volker Siegel (vsiegel)]

There is a very similar case described in a question at unix.stackexchange.com:

"`mount -o loop` changes mounted ISO image file",
http://unix.stackexchange.com/questions/149459/mount-o-loop-changes-mounted-iso-image-file

[Volker Siegel (vsiegel)]

It seems to be not a bug,

according to the answers to that question linked in the previous post.

The iso file is not mounted read only - even if the iso image file may be read only.
That allows for changes in the metadata of the iso file - even if the files in the iso filesystem can not be changed.

Adding the mount option "ro" to explicitly mount read only prevents the changes of the iso or udf image file, solving the problem:

sudo mount -o ro,loop testimage.iso /mnt

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[ppmm (ooev)]

Bug or not, this is a very bad one.

1. Content of .iso file under 99% scenario, is readonly. As far as mount is concerned, it doesn't even have the capability to modify the content of .iso file, it wouldn't make sense to specify 'rw' for mount anyway, not to mention updating the metadata of .iso file this is just too far stretched.

2. In manual it says 'ro Mount the filesystem read-only.' 100% of our use cases would interpret this option as applicable to the content, wouldn't it? But we are talking about the metadata of the .iso file being modified. This is just wrong.

mount should just leave the cd/dvd/blueray etc image file untouched. period.

[ppmm (ooev)]

And may I add:

3. mount totally ignores file level permission and update an iso file with 0444 permission. This is also wrong.

[Karel Zak (kzak)]

The command mount(8) does not write anywhere, if you see any change in the filesystem then it's done by kernel filesystem driver.

I guess the confusing thing for users is that mount(8) command calls mount(2) syscall two times:

# strace -e mount mount /dev/loop0 /mnt/test
mount("/dev/loop0", "/mnt/test", "udf", MS_MGC_VAL, NULL) = -1 EACCES (Permission denied)
mount: /dev/loop0 is write-protected, mounting read-only
mount("/dev/loop0", "/mnt/test", "udf", MS_MGC_VAL|MS_RDONLY, NULL) = 0

The first attempt failed with EACCES, then mount(8) retry with MS_RDONLY. This is expected and wanted behaviour. I guess that kernel udf driver write to the filesystem during the first attempt when it's read-write.

If you try mount with "-o ro" then you won't see the issue.

IMHO udf kernel driver is little bit inconsistent. It does not allow to mount the image read-write, but it modifies the filesystem before it returns EACCES :-)

[Karel Zak (kzak)]

Kernel patch http://www.spinics.net/lists/linux-fsdevel/msg89010.html

[林博仁(Buo-ren, Lin) (buo-ren-lin)]

This is a kernel bug instead of kernel building script bug

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.8 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc2/

[Joseph Salisbury (jsalisbury)]

This bug was fixed upstream as of 4.3-rc1 by commit:
9181f8b udf: Don't modify filesystem for read-only mounts

Can folks affected by this also see if this bug is now fixed in 16.04?

[qji (qji)]

Thanks for checking. Yes, it looks like fixed on Ubuntu 16.04 (but not on 14.04). I've run a test with a dummy image how it's described in the bug report and it works on Ubuntu 16.04, the UDF image is unchanged after mount/umount.

[林博仁(Buo-ren, Lin) (buo-ren-lin)]

I've run into this bug from https://github.com/slacka/WinUSB/issues/34 , the bug reproducer's kernel is 3.16.0-77 running on (seems to be) trusty.

I suggest cherry-pick the fix back to trusty kernel if possible.