[dm-crypt] UUID question

Sven Eschenberg sven at whgl.uni-frankfurt.de
Thu Dec 20 00:30:23 CET 2012


cryptsetup luksUUID <dev> will return the luks header's UUID if <dev>
holds a luks header, and yes, this should usually not change the same way
as the UUID of a filesystem souldn't.

There's 2 problems though:

1.) You'd have to know <dev> in advance or iterate over all possible (non
locked) blockdevices (which is what blkid usually does anyway for you)

2.) a blockdev could possibly hold a luks header and still be part of a md
device (depending on metadata version), you'd better hope that the md
device is set up already, when you issue your cryptsetup commands.

Concerning the original question:

The UUID within the LUKS header should not change throughout the LUKS
volume's lifetime, except for enforced changes (as noted before).

To associated keys based on luks UUID, using something like:
'blkid -t TYPE="crypto_LUKS" -s UUID'
is probably a good starting point, as it gives you the UUID to retrieve
the keys based on the UUID and the device inode you'd use on further calls
to cryptsetup etc. - The rest is just a little shell magic ;-)

Regards

-Sven


On Tue, December 18, 2012 17:46, David Li wrote:
> cryptsetup luksUUID <dev> also shows UUID, Perhaps this is the luks UUID
> that is independent of the partition format.
>
>
> On Tue, Dec 18, 2012 at 12:57 AM, Arno Wagner <arno at wagner.name> wrote:
>
>> On Tue, Dec 18, 2012 at 09:12:01AM +0100, Marc Ballarin wrote:
>> > Am 18.12.2012 01:36, schrieb Arno Wagner:
>> > >On Mon, Dec 17, 2012 at 04:10:50PM -0800, David Li wrote:
>> > >>Hi, I wonder if the dm-crypt partition UUID (shown in blkid -p
>> <dev>)
>> can
>> > >>be used to uniquely associate it with the set of keys the partition
>> will
>> > >>need. Are there any cases that the UUID would change during the
>> partition's
>> > >>lifetime?
>> > >
>> > >The UUID is actually a filesystem attribute, not a partition
>> > >attribute...
>> >
>> > This depends on the partition format in use. For example GPT, and
>> > maybe others, provide an additional UUID for partititons (actually
>> > GPT even supports Labels):
>> >
>> > $ sudo blkid -p /dev/sda1
>> > /dev/sda1: LABEL="data_usb"
>> > UUID="9b70c4bf-6b40-4be3-9cb7-030db682ad35" VERSION="1.0"
>> > TYPE="ext4" USAGE="filesystem" PART_ENTRY_SCHEME="gpt"
>> > PART_ENTRY_UUID="3d18a590-d329-4a82-be02-c3588098d625"
>> > PART_ENTRY_TYPE="0fc63daf-8483-4772-8e79-3d69d8477de4"
>> > PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="2048"
>> > PART_ENTRY_SIZE="3907027087" PART_ENTRY_DISK="8:0"
>> >
>> > Whereas dos/mbr does not:
>> >
>> > $sudo blkid -p /dev/sda1
>> > /dev/sda1: UUID="b786a3a4-26e7-4765-aed1-9bc472522c06" VERSION="1.0"
>> > TYPE="ext4" USAGE="filesystem" PART_ENTRY_SCHEME="dos"
>> > PART_ENTRY_TYPE="0x83" PART_ENTRY_FLAGS="0x80" PART_ENTRY_NUMBER="1"
>> > PART_ENTRY_OFFSET="2048" PART_ENTRY_SIZE="63997952"
>> > PART_ENTRY_DISK="8:0"
>> >
>> > While the GPT UUID should never change, it might happen if some
>> > bogus resizing tool is used.
>> >
>> > So, if a LUKS-UUID is available I would always prefer it and only
>> > fall back to partition UUIDs when not using LUKS.
>> >
>> > Regards,
>> > Marc
>>
>> Interesting. Seems (again), my view of things is too simplistic ;-)
>>
>> Anyways, the gist is that change of UUIDs is not something that
>> should ordionarily happen during the lifetime of whatever
>> carries it.
>>
>> Arno
>> --
>> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
>> arno at wagner.name
>> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
>> 9718
>> ----
>> One of the painful things about our time is that those who feel
>> certainty
>> are stupid, and those with any imagination and understanding are filled
>> with doubt and indecision. -- Bertrand Russell
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>




More information about the dm-crypt mailing list