Re: Patch to support LUKS UUIDs in libblkid

[Theodore Tso <tytso@mit.edu>]

Thanks, I've applied the blkid LUKS patch to the e2fsprogs SCM (modulo
a minor whitespace breakage which I fixed up).

BTW, there appears to be a problem here in udev regarding LUKS
identification:

https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/93921

The problem is that udev sets its magic string in the first 512 bytes
of the partition.  This is dangerous and error-prone, because other
things like boot sectors and BSD disk labels tend to live in the first
512 byte sector.  Hence, many programs are very careful before zapping
the first 512 byte sector.  LUKS was added to the vol_id program very
high in the list of filesystems to be probed, ahead of ext2/ext3, so a
filesystem previously contained a LUKS setup, but then was later
mke2fs'ed to be used as a normal ext2/3 filesyste, may get
misidentified by udev's vol_id as still being a LUKS filesystem if
other fields in the first 512 byte sector cause mke2fs to mistakenly
think there was a BSD disklabel in the sector and thus refuse to zero
it out.

This won't be a problem with blkid, since LUKS is placed *after*
ext3/4.  However, it would be a good idea to check and make sure that
whever is setting up a LUKS partition clears the first and last 32k of
a filesystem, to avoid potential confusion by other in-band filesystem
type checkers.  It would probably be a good idea to (after you make
sure this is done) to submit a patch to the uev folks changing the
probing order of vol_id so that it probes for the LUK filesystem after
ext2/3.   

I am currently consider adding specific kludges to mke2fs that checks
the first couple of bytes of the 512 byte sector for the problematic
filesystem types (NTFS and LUKS), explicitly clearing just those bytes
to avoid future confusion.  But that won't help the existing
filesystems that are out there....

						- Ted