[dm-crypt] Detached headers, multiple drives and UUIDs
7heo at mail.com
Mon Apr 10 22:53:41 CEST 2017
On Mon Apr 10 21:10:51 2017 GMT+0200, Milan Broz wrote:
> On 04/10/2017 08:28 PM, Robert Nichols wrote:
> > On 04/10/2017 08:25 AM, Milan Broz wrote:
> >> On 04/10/2017 03:07 PM, 7heo wrote:
> >>> Hello all,
> >>> I have a question regarding the deported headers in LUKS, and how
> >>> it can be used to simplify the setup of RAID over LUKS:
> >>> The current way to automatically unlock all the drives used in a
> >>> Raid array seems to be to add the same key to all the drives in
> >>> the array.
> >>> However that doesn't work with detached headers for obvious
> >>> reasons. The detached headers can apparently be used on any
> >>> number of devices/files at the same time, with one problem: they
> >>> all have the same UUID. I tried using the --uuid flag with
> >>> luksOpen without success.
> >> You cannot change UUID for activated LUKS device, UUID must match
> >> the header (otherwise libcryptsetup cannot handle many functions).
> > No one is asking to change the UUID of an activated LUKS device.
> > Let's approach this in a different way:
> > Is there any need for the detached header to remain available after
> > the LUKS device has been activated? That is, could I have the
> > detached header on a separate, removable device and, after activating
> > the LUKS device via that header, unmount that separate device and
> > lock it away in a safe? Would that interfere with access to the
> > activated device or interfere with a subsequent luksClose operation?
> Without detached header only some command will work (status will
> return only part of information) but luksClose will work always
> (intentionally - it is expected that user can close device without detached header).
> > I don't see any reason why it should, since "--header" is not
> > mentioned as an option for luksClose (and its aliases). Obviously, no
> > _other_ LUKS operation would be possible without that header.
In other words, aside from format anf open (the very obvious ones), the
other operations needing to read the header are: suspend, resume, status
(partially), and resize. Right?
> > When I try this in CentOS 7 (cryptsetup-1.7.2-1.el7) it seems to work
> > just fine. No, I didn't try any of the "not possible" operations.
> Cryptsetup status should print active device state, other commands
> requires LUKS header to operate.
> > Given that the above is possible, then why could one not modify the
> > UUID in that detached header and use it for a different device, given
> > that one accepts that luksClose is the only possible LUKS operation
> > on that orphaned active device?
> But that's exactly what I suggested :-)
> Copy header, change UUID in it, activate another device.
My question regarding this was to know whether it was possible to
automatically generate temporary derivated headers from a "main header"
(as source). Whether in RAM or as files in a ramdisk (or else). That way
there is no necessity to manually manage a bunch of redundant information.
> In fact, I am actually not sure what was the initial problem now...
The reason why I sent the first mail originally is that I created a
header, and two "encrypted files" as a testbench, and everything worked
fine, excepted for blkid reporting the same UUID for both (distinct) files.
> The UUID is needed when you operate with device with signature
> (so it must have LUKS header). Here duplicates can cause problems.
> If there is no LUKS header on device (detached header), then there
> is no duplicity.
> And the activated device-mapper UUID is something else - it is constructed
> as LUKS prefix plus LUKS header UUID plus activated name (then cannot
> be the same).
Then I have to try to fetch the device mapper again, because that was
what caused all this. I assumed that the device-mapper UUID was directly
derivated from the LUKS UUID.
> So you should be able to activate several devices with detached header
> even with the same UUID. Perhaps some script is just confused by this
> but it is possible...
> (Try it and check dmsetup info -c - you should see the UUID there.)
> IOW you can do:
> cryptsetup luksOpen /dev/device1 name1 --header <detached_LUKS_header>
> cryptsetup luksOpen /dev/device2 name2 --header <detached_LUKS_header>
> cryptsetup luksClose name1
> cryptsetup luksClose name2
> and it will work.
That is great news. It can therefore allow to open all the drives from a
RAID with the same detached header, am I getting that right?
Last question: if I want to make an operation (such as resize or
suspend/resume) on a bunch of drives using the same detached header, if
I supply the header via the option, will that work?
Many thanks, that is great information.
> dm-crypt mailing list
> dm-crypt at saout.de
More information about the dm-crypt