mit-krb5 thread support -- fork safety

[Nicolas Williams]

On Tue, Apr 20, 2004 at 12:33:42PM -0400, Sam Hartman wrote:
> >>>>> "Jeffrey" == Jeffrey Altman <jaltman at columbia.edu> writes:
> 
>     Jeffrey> Nicolas Williams wrote:
>     >> Others could remain valid:
>     >> 
>     >> - krb5_principal - krb5_ccache - krb5_keytab
>     >> 
>     >> 
>     Jeffrey> I don't think a krb5_ccache object can be safely used
>     Jeffrey> after a fork.  The krb5_ccache object is opaque and may
>     Jeffrey> refer to data structures or kernel objects which are not
>     Jeffrey> inheritable.
> 
> I think we're approaching this the wrong way.  What objects do our
> applications need us to keep safe after fork?

I'd like GSS objects to remain fork safe, though with a big caveat for
security contexts that have out-of-sequence detection and/or replay
protection.

This translates, more or less, into fork safety for the following krb5
objects:

 - krb5_principal
 - krb5_ccache
 - krb5_keytab

> It seems clear that if necessary, we could make all krb5 objects safe
> after fork.

With the caveat that some krb5_auth_contexts/GSS security contexts may
not be safe for use by both, parent and child.

Nico
--