mit-krb5 thread support -- fork safety

[Nicolas Williams]

Here's an interesting problem.  I'll describe what PKCS#11 does about it
first, then the problem.

PKCS#11 v2.11, section 7.5.1 says that the behaviour of PKCS#11 in a
child process after fork() is undefined until C_Initialize() is called
in the child, and that all PKCS#11 tokens that the parent had been
logged in to them require that the child log in to them again.

There's good reasons for this, and these might apply to some krb5
implementations.  One good reason is that one thread could be holding a
global mutex when another does a fork() [fork1()], which might lead to a
deadlock in the child process.

This creates a problem for the GSS-API generally and the Kerberos V
GSS-API mechanism specifically, since it would hardly be an expected
result that GSS-API objects (names, creds, contexts) become invalid,
after fork()ing, in a child process.  Then again, the GSS-API spec does
not speak to thread-safety, not even fork(), so perhaps it's reasonable
to apply PKCS#11 fork semantics to the GSS-API and GSS mechanisms.


So, the liveliness of krb5 API objects after fork()ing needs to be
defined.  Similarly with the GSS-API.


I would propose the following:

 - Access to some krb5 API objects in child processes after fork()ing
   should be undefined/invalid:

    - krb5_context
    - krb5_auth_context
    - krb5_keyblock

   Others could remain valid:

    - krb5_principal
    - krb5_ccache
    - krb5_keytab

 - GSS-API objects do survive fork()s, with the mechanism using
   thread_atfork() to ensure the survival of names, credentials and
   security contexts.


Nico
--