Re: Where's the key management patchset at?

[David Howells <dhowells@redhat.com>]

> So
> 
> a) Why should we merge keyfs?

A bunch of people out there (viro, hch, jamesm for example) think they want
it, and in fact think that there shouldn't be any other interface. I've also
had emails of random people saying there absolutely has to be a filesystem
interface so they can as administrators go and rummage around in the key
database, though I suspect they're going to be disappointed in keyfs as it'll
only let them see those keys they've a right to do something with.

I'd like to dispense with keyfs. The semantics of the key database don't map
to the VFS, hence the fact we have to present the key database as a flat
directory and why I have to make use of a bunch of undocumented esoteric fs
ops.

I'd also like keyfs to remain optional at best. It's a large chunk of code
that is completely unnecessary, and on an embedded system it's something you'd
probably want to do without. It could be made a module, I suppose, to be
loaded on demand.

> b) Are people likely to use the APIs frequently enough for its
>    performance to matter?

Now that's harder to judge...

Performance is going to matter very much from the point of view of a
filesystem that wants a key. It's probably going to be checking for a key on
every open call. However, that's mostly taken care of by the internal kernel
API, and the userspace interface has little impact upon that, except where the
request-key callout is concerned.

Performance may also matter from the point of view of userspace service
programs (AFS requires a few of these), though in this case you should only
need to do one lookup per invocation of the program.

So, for most userspace operations wrt to keys, performance isn't a problem;
however, for certain systems, size _is_ a problem and in those cases keyfs is
a liability.

And, before anyone asks, yes, the problem of kernel size is something I've had
to contend with.

David