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

    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*


More information about the krbdev mailing list