lkml.org 
[lkml]   [2004]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Preliminary Linux Key Infrastructure 0.01-alpha1
On Sun, 25 Jul 2004, Kyle Moffett wrote:

> Preliminary Linux Key Infrastructure 0.01-alpha1:
>
> I'm writing a key/keyring infrastructure for the Linux kernel. I've got
> some of the basic infrastructure done, and I'd like any comments on it
> that you may have.

Firstly, it might be useful for other developers if you could write up a
brief rationale about this feature, why it's needed and why this is a good
solution. I do know of a few projects which could make use of keyrings:

- cryptfs (Michael Halcrow)
- afs
- module signing (David Howells/ Arjan)

Are there others (with running code, merged or potentially mergable) ?

Does your design cater for all needs?

I think I heard that Greg-KH had some keyring code already, so there may
be some existing code floating around.

To get more people to look at the code, I'd suggest that you get it
running and prepared as a patch to the mainline kernel. It will also help
if you follow Documentation/CodingStyle and use more idiomatic kernel
development practices.

For example, typedefs are generally frowned upon (but perhaps acceptable
to improve readability of complex function pointer stuff).

You don't need to cast the result of kmalloc:

key = (lki_key_t *)kmalloc(sizeof(lki_key_t),GFP_KERNEL);

should be:

key = kmalloc(sizeof(lki_key_t),GFP_KERNEL);

Avoid using sizeof(some_type) for things like the above, use the actual
object itself:

key = kmalloc(sizeof(*key), GFP_KERNEL);

(in case the type of *key changes some day).

Use wrapper functions like wait_event_interruptible() instead of rolling
your own.

It's better (IMHO) to have one exit path in a function, to clarify error
handling, locking, and make it easier to audit the code. e.g. in
lki_key_used_list_allocate(), you grab a lock then have several return
points with no unlock.

Having some real code which uses the framework will also be good.


> TODO:
> keyctl:
> The syscall that makes it all possible

Why would you need a syscall?

> keyfs:
> keys by number: On hold while I learn more about filesystems :-D

What does this mean?

I would imagine that the entire userspace API would be filesystem based.
e.g. you could load the keys for module signature checking during boot by
writing them to a node like:

cat keyring.txt > /keyrings/modsign/keys

Disable further changes:

echo "0" > /keyrings/modsign/write

You could manage per process credentials via /proc/self/something


- James
--
James Morris
<jmorris@redhat.com>


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

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.229 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site