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. yes.
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?
Milan
Many thanks, that is great information. Theo. _______________________________________________
dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
