From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820075.outbound.protection.outlook.com [40.107.82.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Mon, 4 Nov 2019 15:59:20 +0100 (CET) From: Hualing Yu Date: Mon, 4 Nov 2019 14:59:18 +0000 Message-ID: References: <4eea62ab-e121-d069-9be2-048b09cf301e@gmail.com> <4fd9084a-e78d-6c16-edb7-2dec936023dc@gmail.com> In-Reply-To: Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CH2P132MB0187684C805E914A8A4F67F1877F0CH2P132MB0187NAMP_" MIME-Version: 1.0 Subject: Re: [dm-crypt] 10 M Luks2 header size? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ondrej Kozina , "dm-crypt@saout.de" --_000_CH2P132MB0187684C805E914A8A4F67F1877F0CH2P132MB0187NAMP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ondrej, Yes, I can read the key content when it seems not automatically used to act= ivate (open) the luks partition it assigned to. However, after I did 'keyctl link @us @s' Then 'cryptsetup luksOpen' didn't prompt for passphrase but directly activa= ted the partition (show up under /dev/mapper/) It seem the auto-activation need to have the key in session keyring, not ju= st user session keyring, while as the man page said it only need to be in e= ither @u or @us. I can add this keyring link command every time try to open luks, but I want= to know if we are supposed to do so or this indicated something wrong. Thanks, Hualing -----Original Message----- From: Ondrej Kozina [mailto:okozina@redhat.com] Sent: Monday, November 04, 2019 5:34 AM To: dm-crypt@saout.de Cc: Hualing Yu Subject: Re: [dm-crypt] 10 M Luks2 header size? On 11/3/19 4:33 AM, Hualing Yu wrote: > 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 > > 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? Maybe the key is unreachable from your current session after switching out = from initramfs. Can you read the key payload with "keyctl read " = command? Regards O. --_000_CH2P132MB0187684C805E914A8A4F67F1877F0CH2P132MB0187NAMP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ondrej,

 

Yes, I can read the key content when it seems not= automatically used to activate (open) the luks partition it assigned to.

 

However,  after I did ‘keyctl link @us= @s’

 

Then ‘cryptsetup luksOpen’ didn’= ;t prompt for passphrase but directly activated the partition (show up unde= r /dev/mapper/)

 

It seem the auto-activation need to have the key = in session keyring, not just user session keyring, while as the man page sa= id it only need to be in either @u or @us.

 

I can add this keyring link command every time tr= y to open luks, but I want to know if we are supposed to do so or this indi= cated something wrong.

 

Thanks,

 

Hualing

 

-----Original Message-----
From: Ondrej Kozina [mailto:okozina@redhat.com]
Sent: Monday, November 04, 2019 5:34 AM
To: dm-crypt@saout.de
Cc: Hualing Yu <hualing.yu@jci.com>
Subject: Re: [dm-crypt] 10 M Luks2 header size?

 

On 11/3/19 4:33 AM, Hualing Yu wrote:<= /p>

> Hi Milan

>

> We have problem now 8-)

>

> I did 'cryptsetup format' at initramfs, wher= e I also 'add token' to

> luks passphrase slot 0.

>

> It seems to work as expected in later luksOp= en (without asking me

> passphrase) when still in initramfs.  E= ven next run after power cycle

> reboot.  However after it runs to norma= l rootfs, then when I try to do

> luksOpen still as root user, it ask for pass= phrase.

>

> I can see my passphrases are both in @u and = @us keyring both at

> initramfs time and when run as root in norma= l linux.  However, in

> initramfs, my passphrasses are also in @s, w= hich probably is why in

> initramfs time, I can auto activate (open) m= y luks partitions.

>

> Cryptsetup man page says:

>

> token <add|remove> <device>=

>

>        &n= bsp;       Adds a new keyring token to enable= auto-activation of

> the device.   For  the  = auto-

>

>        &n= bsp;       activation,   the &= nbsp; passphrase  must  be  stored  in

> keyring  with  the  specified=

>

>        &n= bsp;       description. Usually, the passphra= se should  be  stored

> in  user  or  user-session

>

>        &n= bsp;       keyring.  The token command i= s supported only for LUKS2.

>

> My passphrases are in both user and user-ses= sion keyrings, maybe I

> just ran into some unusual case where passph= rases also need to be in

> session keyring.  Do you know what̵= 7;s the reason?

 

Maybe the key is unreachable from your current se= ssion after switching out from initramfs. Can you read the key payload with= "keyctl read <your_key>" command?

 

Regards O.

 

--_000_CH2P132MB0187684C805E914A8A4F67F1877F0CH2P132MB0187NAMP_--