Over a decade later... but this might help someone. There is a way
around this mess, with some caveats. You can set the block device to
readonly using blockdev. This works as desired a lot of the time.
However, sometimes (or perhaps everytime certain filesystems need to
replay the journal), the will cause the kernel to refuse to mount the
filesystem. The way around this is to, as mentioned above, replay the
journal to ram. As far as I know, no filesystems support this natively.
What can be done is to use dm-snapshot to create a snapshot of the block
device with the cow file residing on a tmpfs. Then mount the snapshot
device's filesystem as readonly. In this case the log will be replayed
to ram.

The caveat here is that, when in this state, the underlying block device
should not be written to. So effectively the block device is locked up
until the snapshot device is removed. A scenario where this might be an
issue is as follows. You have a harddrive with isos on an ext4
filesystem that you use to grub iso loopback mount to boot from. When
booting one of the isos, you use the snapshot setup with this filesystem
because you don't know if its part of a hibernation image or not. When
the livecd is up and running, you will not be able to modify the
filesystem (you can write to it, but all changes are in ram and will be
lost). That's as it should be if the filesystem is part of a hibernation
image, but it might be more likely that its not. And in that case, it
might be confusing why this restriction exists.

What would be good is to have code that can detect if the system has a
hibernation image or even better if the filesystem was mounted while a
hibernation happened (not sure if that's possible). Then the snapshot
work around could be done only when needed.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/41624

Title:
  Replaying journals of other OS's filesystems, by mounting them, is
  unsafe

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iso-scan/+bug/41624/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to