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

[David Howells <dhowells@redhat.com>]

> > 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.
> 
> I figured you would write to the file (a keyring id?) and it would return 
> a key id.

What do you mean by return? You can't pass it back as write()'s return
value. I suppose you could then arrange for the fd to be read():-/

> > 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...
> 
> They would contain symlinks to keyring IDs.

Yes, but given that the targets of the symlinks would not be in /proc, how do
you concoct the symlink. I suppose you could assume "/sysfs/keys/<keyid>" as
the target, but that's not very nice.

> > 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?
> 
> No.  The reason for suggesting this was because with a filesystem API, the 
> information is already available in userspace, and it would be quite 
> simple to enumerate it.  As you said, it's not something that would happen 
> all the time, so it's not performance critical.  But if you need a kernel 
> API for the same thing, it's a moot point.

It would be quite an involved process to do this in userspace. You'd have to
walk through a nest of keyrings, and you'd have to do a lot of file opening,
and closing (possibly 2 per key: type and description, though these could be
available through the same file) and reading of dirs and symlinks.

Maintaining access controls would be fun though... How does the kernel then
distinguish between a read and a search?

David