ccache using linux Keyrings

[Frank Cusack]

On April 14, 2006 9:47:11 AM -0600 "Wachdorf, Daniel R" <drwachd at sandia.gov> wrote:
> 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.

I've always wanted to add a hook to gssd so that you could "forcibly" give
credentials to or revoke credentials from it.  Rather than have gssd search
the filesystem.  Shouldn't be hard, just never got a round tuit.  That'd
solve the well-known name problem.

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

I don't see how, unless it's a real PAG-like thingy, which AFAIK the Linux
keyring is not.  The kernel will still have to look for a well known keyring.

BTW, it's not just NFSv4, it's nfs/gss (and as Nico points out, it's not
just kerberos).  I've been using gss (krb5) with nfsv3 for a few years now.

-frank

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