[Bug 531240] Re: breaking raid: root raid_member opened as luks

[ceg]

> blkid currently, deliberately, returns only the first detected RAID or LUKS container
> for a filesystem - with the checking order being raid first.

Did someone change it already?

The issue I reported is actually the other way around. A RAID member
device partition  (version 0.90 metadata, located at the end of the
device) where the assembled raid contained LUKS was identified as being
LUKS. Leading to a random raid member being opened and mounted instead
of the then degraded raid device (corrupting of the raid integrity).


AFAIK:
blkid was patched more lately to give LUKS priority over fs signatures, because cryptsetup missed to wipe existing metadata at least in the past. (In addition to giving RAID priority over FSs.) But with this change, LUKS was also (errornously) given priority over RAID, leading to the issue at hand.

I think RAID must have priority not only over FSs but also over LUKS.

Because RAID should regularly be able to contain LUKS and in this case
both metadata will be there, but if LUKS really contains RAID, the RAID
metadata would regularly be encrypted.

Now, if the device really is LUKS and there is leftover RAID metadata
present (Is cryptsetups actually wiping the end of devices, or only
filesystem metadata at the beginning?) there is the following risk: If
different luks partitions are created on  raid1 partitions marked clean
and consistent, they would get assembled into an inconsistent array.

If it may be possible for cryptsetup to open such a device (if chunksize
larger than metadata?) cryptsetup would have to safeguard against
opening this.

Two things to check with cryptsetup: Wiping end? Opening inconsisten
raid?

-- 
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to util-linux in ubuntu.