ccache using linux Keyrings

[Frank Cusack]

On April 13, 2006 9:37:47 AM -0500 Nicolas Williams <Nicolas.Williams at sun.com> wrote:
> On Wed, Apr 12, 2006 at 06:42:31PM -0700, Frank Cusack wrote:
>> On April 12, 2006 6:37:25 PM -0700 Frank Cusack <fcusack at fcusack.com> wrote:
>> > Sorry for my late entry into this thread, and more importantly, that I
>> > haven't read the entire thread (I missed the beginning).
>> >
>> > What is the *point* of using a kernel keyring?
>
> It's like a PAG.

Not without associated handling, though.  Just having a keyring that
isn't referenced except by userland apps is basically shared memory.
Perhaps with finer-grained access control.

>> eh, I just thought of one, after reviewing some older messages in this
>> thread.  Can gssd be eliminated?
>
> Probably not.  See the "Solaris ssh pam_krb" thread on kerberos at mit.edu
> two weeks ago.

OK, I looked at that thread (whew) and from that I don't see why gssd
would have to stay around.

> You can't avoid some upcalls in general without putting too much
> complexity into the kernel.  Examples abound.  E.g., do you want IKE
> exchanges triggered by outgoing packets to be done in-kernel?

Not in general, but isn't gssd specific to nfs/gss?  But that does
remind me of one issue where gssd couldn't go away: it might have to
obtain a new session ticket.  You don't want that in the kernel.

OK, given that gssd can't go away, I don't see the point of using the
Linux kernel keyring.  Data can be got out of it by the proper uid just
as data can be gotten out of FILE: ccaches.  Yes?

-frank