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

From: James Morris
Date: Mon Aug 09 2004 - 09:12:53 EST


On Mon, 9 Aug 2004, David Howells wrote:

> James Morris <jmorris@xxxxxxxxxx> 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.

I figured you would write to the file (a keyring id?) and it would return
a key id.

> > 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...

They would contain symlinks to keyring IDs.

> 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.

> Or would you, say, suggest a new open() syscall that takes a key ID in
> addition?

No, that would require changes to userspace code.


- James
--
James Morris
<jmorris@xxxxxxxxxx>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/