ccache using linux Keyrings

[Wachdorf, Daniel R]

You really don't want to have GSSD searching the file system to find the right credentials cache for a user.  First, it doesn't have access to the environmental information - so if the credentials are not within the default location it will have to go find them.  
 
Second, this really prevents any multi credential per UID access model.   You would not be able to have multiple Kerberos credentials when doing nfsv4.  
 
I think the hope is that keyring credentials cache will provide a way of allow per thread an per process credentials when using NFSv4.
 
-dan

________________________________

From: krbdev-bounces at mit.edu on behalf of Frank Cusack
Sent: Fri 4/14/2006 2:37 AM
To: Nicolas Williams
Cc: krbdev at mit.edu
Subject: Re: ccache using linux Keyrings



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
_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev