merged linux keyring code
hartmans at MIT.EDU
Tue Oct 3 11:17:29 EDT 2006
>>>>> "Kevin" == Kevin Coffman <kwc at citi.umich.edu> writes:
>> 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
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.
More information about the krbdev