merged linux keyring code

[Ken Raeburn]

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


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.

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.

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?

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

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

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?