merged linux keyring code

[Kevin Coffman]

On 10/2/06, Ken Raeburn <raeburn at mit.edu> wrote:
> Hi, Kevin.  Sam asked me to merge in your keyring branch to the krb5
> trunk.  I've checked in the result of my merge, but I made a few
> changes, and had a few questions... please have a look at the result
> and make sure it's sane. :-)
>
> Ken

Cool.  Thanks!  I'll test it out.

> Changes:
>
> aclocal.m4: Enable keyring ccache if the header and library are
> available; no configure-time option, no error if it's not found.
>
> ccdefname.c: Keep old default of FILE: cache, at least for now.

These two together seems fine.

> libkrb5.exports: Don't need to export krb5_krcc_ops.
>
> ccbase.c: Only initialize krb5int_krcc_mutex if USE_KEYRING_CCACHE;
> destroy it in finalization.  Define INITIAL_TYPEHEAD macro (for file
> vs keyring), and use it for initialization and in krb5int_cc_finalize.
> Re-enable freeing of additional registered-type structures.
>
> cc_keyring.c: Avoid calls to com_err from within library.
>
> cc_file.c: Punt change for now; generate_new is badly broken, and we
> hope to replace it with a new API anyways.

Yes, I only found it because I was trying to compare keyring vs.
memory vs. file, and file didn't work.

> Questions:
>
> In start_seq_get, it appears that the iterator will process no more
> than the number of keys that existed when resolve was called.  (Plus
> one, potentially, because of the magic entry holding the principal
> name.)  Perhaps it should use key_read_alloc instead?

Actually, numkeys is updated in store_cred() and should always be
up-to-date.  I probably could have implemented remove_cred() and
updated the numkeys count there too, but does anything depend on it
doing anything?

> In next_cred a comment refers to a linked list, but it looks like a
> flat array to me, right?

Yes.  I started with a copy of cc_memory and missed some comment changes.

> Is libkeyutils always installed on reasonably modern Linux systems?
> (Including, say, Debian's current "stable" release.)  Would it make
> sense to try loading at run time, so one set of binaries can work with
> or without it?  Or just let the package maintainer decide which way to
> go, and what dependencies to add....

There are two parts.  First, the kernel support is optional, so the
basic kernel keyring support may or may not be present.  (It is only
available in 2.6.11-ish and later.)  Then there is the user-land
library.  I'm not sure if Debian or SuSe are enabling keyring support
in their kernel, or if they include the library by default.  The
keyring support came from a Redhat person, so their newer releases
definitely have it.

A runtime test and calling krb5_cc_register() might be made to work.
Of course the header that goes with libkeyutils is still necessary to
compile it.

> I see some stuff in the code referring to sessions, but from my
> experimentation, the default seems to be for the stored data to be
> per-user, available from all the user's login sessions.  Is that
> correct?

Yes.  The session keyring is roughly equivalent to an afs pag.  At
least the inheritance model is based on the pag inheritance.  So
credentials put in the session keyring should be available from all
processes sharing that session keyring.