Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] implement in-kernel keys & keyring management [try #2] | Date | Mon, 09 Aug 2004 10:33:50 +0100 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |