One of the problems with ReiserFS was that a fsck --rebuild-tree would look through all the disk contents for blocks that appeared to be metadata. A hostile user could create a file in their home directory (or /tmp or anywhere else) that contained ReiserFS metadata which would be linked into the filesystem on a --rebuild-tree, by doing that I created a SUID root file as non-root on a ReiserFS system. Also ReiserFS was inherently unsuitable for storing filesystem images as that could mess up the filesystem. I believe that BTRFS uses a UUID for each filesystem that is included in every metadata block which will make it very unlikely that two runs of mkfs.btrfs will result in the same UUID. Therefore there should be no risk of a filesystem image stored in a file messing up a filesystem. Is it possible for a hostile user to create a file that could get linked in to a filesystem by btrfsck? /dev/disk/by-uuid/ is world readable so the UUID of the filesystem is not secret. Apart from the fact that a correct tree (which can be verified by checksums) won't link to data blocks as metadata what assurance do we have that hostile or corrupt data blocks can't be treated as metadata? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
