On Tue, 2015-12-15 at 14:18 +0000, Hugo Mills wrote: > That one's easy to answer. It deals with a major issue that > reiserfs had: if you have a filesystem with another filesystem image > stored on it, reiserfsck could end up deciding that both the metadata > blocks of the main filesystem *and* the metadata blocks of the image > were part of the same FS (because they're on the same block device), > and so would splice both filesystems into one, generally complaining > loudly along the way that there was a lot of corruption present that > it was trying to fix. Hmm that's a bit strange though, and to me it rather sounds like other bugs... You can have a ext4 on a file in an ext4, with or without the same UUIDs, and it will just work. If the filesystem takes contents from a normal file as possible metadata, than something else is severely screwed up... or in case of the fsck: it probably means it's a bit too liberal in searching places.
I'd be quite shocked if this is the case in btrfs, cause it would mean again, that we have a vulnerability against UUID collisions. Imagine some attacker finds out the UUID of a filesystem (which is probably rather easy)... next he uploads some file (e.g. it's a webserver with allows image uploads, a forum perhaps) that in reality contains what's looks like btrfs metadata and uses a matching UUID. It would run into the same issues as what you describe for reiser,.. the UUID would be no real help to solve that problem. Does anyone know whether btrfsck (or other userland) tools do such things? I.e. search more or less arbitrary blocks, where it cannot be sure it's *not* data, for what it would interpret as meta-data subsequently? CHeers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
