On Sat, 2015-12-05 at 13:19 +0000, Duncan wrote: > The problem with btrfs is that because (unlike traditional > filesystems) > it's multi-device, it needs some way to identify what devices belong > to a > particular filesystem. Sure, but that applies to lvm, or MD as well... and I wouldn't know of any random corruption issues there.
> And UUID is, by definition and expansion, Universally Unique ID. Nitpicking doesn't help here,... reality is they're not,.. either by people doing stuff like dd, other forms of clones, LVM, etc. ... or as I've described maliciously. > Btrfs > simply depends on it being what it says on the the tin, universally > unique, to ID the components of the filesystem and assemble them > correctly. Admittedly, I'm not an expert to the internals of btrfs, but it seems other multi-device containers can handle UUID duplicates fine, or at least so that you don't get any data corruption (or leaks). This is a showstopper - maybe not under lab conditions but surely under real world scenarios. I'm actually quite surprised that no-one else didn't complain about that before, given how long btrfs exists. > Besides dd, etc, LVM snapshots are another case where this goes > screwy. > If the UUID isn't UUID, do a btrfs device scan (which udev normally > does > by default these days) so the duplicate UUID is detected, and btrfs > *WILL* eventually start trying to write to all the "newly added" > devices > that scan found, identified by their Universally Unique IDs, aka > UUIDs. > It's not a matter of if, but when. Well.. as I said... quite scary, with respect to both, accidental and malicious cases of duplicate UUIDs. > And the UUID is embedded so deeply within the filesystem and its > operations, as an inextricable part of the metadata (thus avoiding > the > problem reiserfs had where a reiserfs stored in a loopback file on a > reiserfs, would screw up reiserfsck, on btrfs, the loopback file > would > have a different UUID and thus couldn't be mixed up), that changing > the > UUID is not the simple operation of changing a few bytes in the > superblock > that it is on other filesystems, which is why there's now a tool to > go > thru all those metadata entries and change it. I don't think that this design is per se bad and prevents the kernel to handle such situations gracefully. I would expect that in addition to the fs UUID, it needs a form of device ID... so why not simply ignoring any new device for which there already is a matching fs UUID and device ID, unless the respective tool (mount, btrfs, etc.) is explicitly told so via some device=/dev/sda,/dev/sdb option. If that means that less things work out of the box (in the sense of "auto-assembly") well than this is simply necessary. data security and consistency is definitely much more important than any fancy auto-magic. > So an aware btrfs admin simply takes pains to avoid triggering a > btrfs > device scan at the wrong time, and to immediately hide their LVM > snapshots, immediately unplug their directly dd-ed devices, etc, and > thus > doesn't have to deal with the filesystem corruption that'd be a when > not > if, if they didn't take such precautions with their dupped UUIDs that > actually aren't as UUID as the name suggests... a) People shouldn't need to do days of study to be able to use btrfs securely. Of course it's more advanced and not everything can be simplified in a way so that users don't need to know anything (e.g. all the well-known effects of CoW)... but when the point is reached where security and data integrity is threatened, there's definitely a hard border that mustn't be crossed. b) Given how complex software is, I doubt that it's easily possible, even for the aware admin, to really prevent all situations that can lead to such situations. Not to talk about about any attack-scenarios. > And as your followup suggests in a security context, they consider > masking out their UUIDs before posting them, as well, tho most kernel > hackers generally consider unsupervised physical access to be game- > over, > security-wise. Do they? I rather thought many of them had a rather practical and real- world-situations-based POV. > (After all, in that case there's often little or nothing > preventing a reboot to that USB stick, if desired, or simply yanking > the > devices and duping them or plugging them in elsewhere, if the BIOS is > password protected, with the only thing standing in the way at that > point > being possible device encryption.) There's hardware which would, when it detects physicals intrusion (like yanking) lock up itself (securely clearing the memory, disconnecting itself from other nodes, which may be compromised as well, when the filesystem on the attacked node would go crazy. You have things like ATMs, which are physically usually quite well secured, but which do have rather easily accessible maintenance ports. All of us have seen such embedded devices rebooting themselves, where you see kernel messages. That's the point where an attacker could easily get the btrfs UUID: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.2.0-1-amd64 root=UUID=bd1ea5a0-9bba-11e5-82fa-502690aa641f If you can attack such devices already by just having access to a USB port... then holly sh**... > The only real > alternative if > you don't like it is using a different filesystem. As I've said, I don't have a problem with UUIDs... I just can't quite believe that btrfs and the userland cannot be modified so that it handles such cases gracefully. If not, than, to be quite honest, that would be really a major showstopper for many usage areas. And I'm not talking about ATMs (or any other embedded devices where people may have non-supervides access - e.g. TVs in a mall, entertainment systems in planes) but also the normal desktops/laptops where colleagues, fellow students, etc. may want to play some "prank". Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
