ccache using linux Keyrings
fcusack at fcusack.com
Fri Apr 14 04:37:33 EDT 2006
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?
More information about the krbdev