|
Hi Milan We have problem now 8-) I did 'cryptsetup format' at initramfs, where I also 'add token' to luks passphrase slot 0. It seems to work as expected in later luksOpen (without asking me passphrase) when still in initramfs. Even next run after power cycle reboot. However after it runs to normal rootfs, then when I try to do luksOpen still as root user,
it ask for passphrase. I can see my passphrases are both in @u and @us keyring both at initramfs time and when run as root in normal linux. However, in initramfs, my passphrasses are also in @s, which probably is why in initramfs time, I can auto activate
(open) my luks partitions. Cryptsetup man page says: token <add|remove> <device> Adds a new keyring token to enable auto-activation of the device. For the auto- activation, the passphrase must be stored in keyring with the specified description.
Usually, the passphrase should be stored in user or user-session keyring. The token command is supported only for LUKS2. My passphrases are in both user and user-session keyrings, maybe I just ran into some unusual case where passphrases also need to be in session keyring. Do you know what’s the reason? Thank you! Hualing -----Original Message----- Hi Milan, Great! This helps a lot! I'm going to design our redundant file systems around this. I'm looking forward for your article on better using JSON area. No more question now, at this moment 8-) We definitely will encounter somethings later when implementing this. Will bother you again then. And I'll let you know how we make it here no matter what. Again, very appreciate all you helps, your time and expertise! Best regard, Hualing -----Original Message----- From: Milan Broz [mailto:gmazyland@xxxxxxxxx] Sent: Tuesday, October 29, 2019 9:08 AM To: Hualing Yu <hualing.yu@xxxxxxx>;
dm-crypt@xxxxxxxx Subject: Re: 10 M Luks2 header size? On 28/10/2019 14:50, Hualing Yu wrote: > I am sorry that I cannot resist asking more questions as your answer
> indicate more opportunities 8-) If they are very simple to you to
> answer, thank you for just drop a few lines; if not, you can simply
> ignore. > > 1. You said “…if you have no extra user JSON data stored there”. > Can we use that area to store additional user data? How? You can create custom token type and import directly JSON through cryptsetup token import command. There is just mandatory type object, otherwise it can be arbitrary valid JSON. (I plan to write some article about it but I promised this months ago ... :-) > 2. To check if a LUKS is in good condition, can we just use > isLuks command? Does this cmd trigger some internal sanitary
> checking? Hm, in theory yes (it calls functions that will do autorecovery), so side effect is that it validates JSON areas. But note that any LUKS load will recover invalid JSON area if there is one area valid (it requires access to cryptsetup locks directory and of course write access rights to the image/device). IOW it should "autorepair". If not possible, commands starts to fail as there is no LUKS2 header. Milan |
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
