Unbelievable, just lost 6h of my life to Linux fs API "misdesign". So let's say you have a disk image file with an ext4 fs, it's read-only, you want to mount it read-only. So you read-only attach it to a loopback device (i.e. O_RDONLY open + LO_FLAGS_READ_ONLY). Because you are…
…extra careful you even check with BLKROGET and yes, it tells you: this block device is read-only. So you go on, and mount it read-only, i.e. mount() with MS_RDONLY. One would assume because everything in this chain was explicitly done read-only frickin' ext4 wouldn't modify…
… the original file. Ha, you are so naive, of course it does! All these read-only flags don't matter a thing, ext4 writes whenever it wants to. Read-only access is for wussies, real kernel code doesn't care about explicitly specified flags on every level. ext4 doesn't, …
… the block layer doesn't, the loopback device doesn't, and the backing file system doesn't either. Apparently you have to explicitly specifiy "noload" as mount option too, which is ext4 specific. Only then read-only means read-only. xfs apparently has a different option even…
… and other file systems don't have either. So if you actually care about immutable systems, you must maintain a table of extra flags to specify for each fs, to actually get read-only behaviour. Does this matter? Yes, I think it does very much, because mounting the same file…
…multiple times is typically assumed to be safe, as long as it is all done read-only. Except that it currently almost never actually is. #ragetweet
• • •
Missing some Tweet in this thread? You can try to
force a refresh
