On 07/19/2018 02:28 PM, Dave Jiang wrote:
>
>
> On 07/19/2018 01:22 AM, David Howells wrote:
>> Dave Jiang <[email protected]> wrote:
>>
>>> Ok stupid question David. I'm attempting to use the logon-type key. I
>>> have added this line to the request-key.conf:
>>> create logon nvdimm* * /usr/sbin/nvdimm-upcall %k
>>
>> Can you show me the whole file?
> https://lists.01.org/pipermail/linux-nvdimm/2018-July/016958.html
>
> I don't believe /sbin/request-key is calling my upcall app.
Ok I got this part working. I didn't realize that request-key looks for
<key type>.conf and I needed to add my line to /etc/request-key.conf and
/etc/request-key.d/nvdimm.conf no longer works.
>
>>
>> Let me ask a stupid question too: Why do you need to call request_key()?
>>
>> As I understand it, you poke an attribute file in sysfs by writing "update"
>> to
>> it and this triggers a request_key() call. The kernel then links the key it
>> found across to the internal keyring.
>
> Correct. And when there isn't a key, it needs to fetch from userspace
> and construct the key.
>
>>
>> You could instead require that the key be specified directly, ie. you write
>> "update <keyid>" to the attribute file. The driver can then call
>> key_lookup()
>> to get the key - or, better still, we should make lookup_user_key() available
>> so that you can call that - which will do a security check.
>
> I can attach the keyid to the nvdimm when I initially get a success key
> and the update can look it up easily enough. I'm not groking the
> lookup_user_key() comment. What determines a key to be a user key or a
> kernel key?
>
> I think right now the issue I have is trying to get logon key type
> working with creating the initial key from userspace and/or update the
> key with new passphrase, which needs a payload from userspace.
>
>>
>> Another advantage of doing this is that the old key is still available in the
>> internal keyring until it gets replaced. So you can do your password change
>> if you want to do it this way.
>>
>> On the other hand, requiring both the old and the new passwords to be
>> supplied
>> is probably better from a security point of view, so you could require them
>> both to be included in the key.
>>
>> David
>>
> _______________________________________________
> Linux-nvdimm mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/linux-nvdimm
>
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
