merged linux keyring code

[Sam Hartman]

>>>>> "Kevin" == Kevin Coffman <kwc at citi.umich.edu> writes:

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

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

What happens when someone else in another process stores a credential?

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

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

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

I think the right way to do this is to depend on the library if
available at compile time and never to select the keyring cache as the
default if kernel support is not available in the current system.