Re: attacking btrfs filesystems via UUID collisions?

["S.J." <sorry@anonym.com>]

> 1. better practices, we really need to tell users, and documentation
> writers, that using dd (or variant) to copy Btrfs volumes has a
> consequence and should not be used to make copies.

> 2. Btrfs needs a better way to make a copy of a volume when there are
> snapshots (including even rw snapshots); e.g. permit send/receive to
> work on rw snapshots if the fs is ro mounted; e.g. a way to do
> "recursive" send/receive.

> 3. Some way to fail gracefully, when there's ambiguity that cannot be
> resolved. Once there are duplicate devs (dd or lvm snapshots, etc)
> then there's simply no way to resolve the ambiguity automatically, and
> the volume should just refuse to rw mount until the user resolves the
> ambiguity. I think it's OK to fallback to ro mount (maybe) by default
> in such a case rather than totally fail to mount.

About 3:
RO fallback for the second device/partitions is not good.
It won't stop confusing the two partitions, and even if both are RO,
thinking it's ok to read and then reading the wrong data is bad.

About 1 and 2 ... if 3 gets fulfilled, why?
DD itself is not a problem "if" the UUID is changed after it
(which is a command as simple as dd), and if someone doesn't
know that, he/she will notice when mount refuses to work
because UUID duplicate.


PS: Kudos to C.A. Mitterer for discovering that problem