ccache using linux Keyrings
Sam Hartman
hartmans at MIT.EDU
Sat Apr 15 16:37:27 EDT 2006
>>>>> "Jeffrey" == Jeffrey Altman <jaltman at MIT.EDU> writes:
Jeffrey> There is an assumption being made that a thread has a
Jeffrey> single credential cache
no, there is an assumption being made that a thread has a single
keyring cache that can be identified as the right cache to use if you
can't figure out anything better.
Jeffrey> and in the krb5 api the
Jeffrey> association is not between a thread or a process and a
Jeffrey> credential cache but between a krb5_context and a
Jeffrey> credential cache.
However in various ccache types there are additional associations.
For example the api: cache type has the idea of a system default
(really session default) ccache. If this is reasonable, it is
reasonable for the keyring cache to have a session, thread and process
default.
Jeffrey> The existing usage models are not compatible with a file
Jeffrey> system or device driver that needs access not simply to a
Jeffrey> credential cache but to *the* security context associated
Jeffrey> with the thread either through direct assignment or
Jeffrey> inheritance from the process or security session.
The filesystem does not require there be one krb5_context, it simply requires that it know which ccache to use.
Jeffrey> The
Jeffrey> conflict between the two models is that the krb5 api
Jeffrey> allows a many to many association of krb5_context and
Jeffrey> threads. Whereas the requirements of a file system or
Jeffrey> driver are a one to one association of krb5_context to
Jeffrey> thread.
*for the specific purpose of kernel access*
--Sam
More information about the krbdev
mailing list