Re: [PATCH] implement in-kernel keys & keyring management [try #2]

[David Howells <dhowells@redhat.com>]

James Morris <jmorris@redhat.com> wrote:
> Implement a filesystem interface, e.g. /proc/<pid>/keys
> 
> From here you can have:
> 
>   /create

How would this work? Remember you've got to get some data back, and you've got
to simultaneously attach your key to a keyring, otherwise it'll just be erased
immediately.

>   /<keyid>/update
>           /revoke
>           /chown
>           /chmod
>           ...

I could. You're going a little far: chown and chmod can be done by other
methods on the <keyid>/ directory.

> Rather than syscalls/prctls for each of these.

It'd require a lot more code and memory to do it with a filesystem, I think.

> For keyrings, you could have:
> 
>   /proc/<pid>/keyring/thread
>                      /session
>                      /process
>                      ...

What are these? Files containing keyring ID numbers? If so, better to just
have one file from whence you can read all the IDs, and since /proc/pid/status
has to grab the requisite lock anyway...

> Instead of having /proc/keys and associated locking/seqfile overhead in 
> the kernel, a userspace library could instead traverse /proc to build a 
> global list of keys.

And incur even more locking overhead? Besides, why? Looking at all the keys on
the system isn't something that should be done very often, and what you're
suggesting would be more expensive in the long run.

> In general, I think you may be able to move logic out of the kernel this 
> way, e.g. userspace searching for keys.

But you need to lock the keyrings as you search. Access controls also need
to be enforced, but that could probably be done in userspace (you can't scan
the contents of a keyring you don't own).

Besides, the search _has_ to be available in kernel space. A filesystem such
as AFS or NFS would need to be able to call it during file->open(), and maybe
at other times. Would you suggest that it should call out to userspace to do
the keyring search? Or would you, say, suggest a new open() syscall that takes
a key ID in addition?

And since there has to be a kernel space search routine, why not make it
available to userspace too?

David