Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

From: Ahmad Fatoum
Date: Tue Aug 24 2021 - 03:33:49 EST


On 23.08.21 19:50, Tim Harvey wrote:
> On Mon, Aug 23, 2021 at 6:29 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote:
>> On 20.08.21 23:19, Tim Harvey wrote:
>>> On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote:
>>>> On 20.08.21 22:20, Tim Harvey wrote:
>>> It works for a user keyring but not a session keyring... does that
>>> explain anything?
>>> # keyctl add trusted mykey 'new 32' @u
>>> 941210782
>>> # keyctl print 941210782
>>> 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
>>> # keyctl add trusted mykey 'new 32' @s
>>> 310571960
>>> # keyctl print 310571960
>>> keyctl_read_alloc: Unknown error 126
>>
>> Both sequences work for me.
>>
>> My getty is started by systemd. I think systemd allocates a new session
>> keyring for the getty that's inherited by the shell and the commands I run
>> it in. If you don't do that, each command will get its own session key.
>>
>>> Sorry, I'm still trying to wrap my head around the differences in
>>> keyrings and trusted vs user keys.
>>
>> No problem. HTH.
>
> Ahmad,
>
> Ok that explains it - my testing is using a very basic buildroot
> ramdisk rootfs. If I do a 'keyctl new_session' first I can use the
> system keyring fine as well.

Great. Does this mean I can get your Tested-by: ? :)

> Thanks - hoping to see this merged soon!

You and me both.

Cheers,
Ahmad


>
> Tim
>


--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |