Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] implement in-kernel keys & keyring management | Date | Mon, 09 Aug 2004 10:23:20 +0100 |
| |
Greg KH <greg@kroah.com> wrote: > I think that if the /proc interface was moved over to sysfs (which is > where it should be), a number of these syscalls would go away.
Well, I could move these two files into /sysfs. But just doing that wouldn't get rid of any of the system calls. To move these files into sysfs, should I create a "keys" subsystem?
Can you elaborate as to what you envision? I wonder if you'd thinking that I should make every key a kobject and fan-out them out in a directory in sysfs somewhere. I really don't want to do that, though... kobject seems to add quite a large overhead that I'd rather avoid (a directory in sysfs for instance).
I could a keyfs filesystem, fan the keys out in there, but this would spawn more code than just a few new syscalls or prctls. However, I can't just pretend all keyrings are directories and all keys files and then use link() and unlink(). I'd need to be able to link() and unlink() directories. I could do it by representing two keyrings, as two adjacent directories, and then use symlink() to create a link between them.
The main advantage of doing this, however, is that shell scripts would be able to modify their own keyrings without a utility program such as keyctl.c that I put up for download.
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/
| |