lkml.org 
[lkml]   [2004]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] implement in-kernel keys & keyring management
Date

James Morris <jmorris@redhat.com>
> I'm not disagreeing with the above, but what about performance? Part of
> the reason I suggested Netlink is that it's likely to be more efficient to
> send messages over a socket than to exec a program for each key request
> from the kernel.
>
> It's difficult to know if performance will actually be an issue without
> understanding the potential workload more. What if many thousands of
> clients are connected to a fileserver? Would calling /sbin/request-key
> for each key request be likely to cause performance problems?

I have put in one thing to mitigate this problem. There's a construction
queue. If a user has a key under userspace construction with a particular type
and description, then anyone else who wants the same key will have to wait for
the key construction to complete, and then repeat their search.

The assumption is that the constructor will instantiate the key and link it
into one of the calling process's keyrings (probably the session
keyring). This then acts as a cache, where subsequent key accesses should
hopefully find it.

However, there are two issues this.

(1) Key lookup failure: I think that maybe I need to add the concept of a
"negative" key.

Key search would then proceed in this manner: the keyring tree is
searched for a positive key, terminating the search when one is
found. Any matching negative keys are noted in passing, but nothing is
done about them until the search fails; in which case an error will be
returned immediately rather than going to userspace.

(2) What if the new key is not made available to the next process that wants
it, perhaps because it's in a different session? Should it be possible
for the constructor to say "don't use this key, use that one instead",
and substitute an existing key from its cache?

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/

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