On Tue, 2015-12-15 at 08:54 -0500, Austin S. Hemmelgarn wrote: > Except for one thing: Automobiles actually provide a measurable > significant benefit to society. What specific benefit does embedding > the filesystem UUID in the metadata actually provide? I guess that's quite obvious. You want something that can be used to address devices stable (i.e. not their "path" like sda,sdb). So either some ID or a label. Human readable lables are basically guaranteed to collide, so UUIDs are the clean solution. Since there is however no guarantee that they don't collide (either by accident or malicious intent), you need to protect against that.
Analogous for the device IDs of multi-device fs or containers. > > "A UUID is 128 bits long, and can guarantee uniqueness across space > > and time." > > > > Also see security considerations in section 6. > Both aspects ignore the facts that: > Version 1 is easy to cause a collision with (MAC addresses are by no > means unique, and are easy to spoof, and so are timestamps). > Version 2 is relatively easy to cause a collision with, because UID > and > GID numbers are a fixed size namespace. > Version 3 is slightly better, but still not by any means unique > because > you just have to guess the seed string (or a collision for it). > Version 4 is probably the hardest to get a collision with, but only > if > you are using a true RNG, and evne then, 122 bits of entropy is not > much > protection. > Version 5 has the same issues as Version 3, but is more secure > against > hash collisions. I guess we don't need to discuss how unique UUIDs are when they're *freshly created*, since this is the only thing what the RFC "guarantees"... That's mostly irrelevant for us here, as we have two far more stronger cases, accidental duplication and malicious collisions. The possible case, that by normal means (e.g. mkfs.btrfs) a UUID collision occurs, are small, but solving the actual two cases here, will solve that one as well. Apart from that, I've noticed in several of your mails that either something with the indention level goes wrong, or you mix contents from multiple mails from different people. E.g. that "Also see security considerations in section 6." wasn't from me, which was at quotation level 1 in your mail, but the example with the automobile, which was also on level 1, was from me. That's kinda confusing... > In general, you should only use UUID's when either: > a. You have absolutely 100% complete control of the storage of them, > such that you can guarantee they don't get reused. > b. They can be guaranteed to be relatively unique for the system > using them. No, this aren't necessary constraints. And in fact would make multi- device practically impossible (you always need some ID, unless you want to open the door for countless of errors, where people wrongly assemble their devices... whether it's UUID or anything else, doesn't matter). The only thing that one needs to do, is handle collisions gracefully and don't do auto-assemblies,.. all as I've described in the mail from "Fri, 11 Dec 2015 23:06:03 +0100" (http://thread.gmane.org/gmane.comp.file-systems.btrfs/50909/focus=51147) > > There could be some leveraging of the device WWN, or absent that > > its > > serial number, propogated into all of the volume's devices (cross > > referencing each other's devid to WWN or serial). And then that way > > there's a way to differentiate. In the dd case, there would be > > mismatching real device WWN/serial number and the one written in > > metadata on all drives, including the copy. This doesn't say what > > policy should happen next, just that at least it's known there's a > > mismatch. > > > That gets tricky too, because for example you have stuff like flat > files > used as filesystem images. plus... one cannot be sure whether any hardware device IDs, like serial numbers, are unique... a powerful attacker could surely change these as well. Or imagine you have a failing harddisk, and dd it's content to another... the btrfs part would stay identical, while the hardware device IDs change and confuse everything. > However, if we then use some separate UUID (possibly hashed off of > the > file location) in place of the device serial/WWN, that could > theoretically provide some better protection. Not really... it just delegates the problem one level further. The only real protection is, that the kernel and userland tools deal correctly with the situation. > The obvious solution in > the case of a mismatch would be to refuse the mount until either the > issue is fixed using the tools, or the user specifies some particular > mount option to either fix ti automatically, or ignore copies with a > mismatching serial. Sure, as I've said before :-) Cheers, Chris
smime.p7s
Description: S/MIME cryptographic signature
