mit-krb5 thread support -- fork safety
Nicolas.Williams at sun.com
Tue Apr 20 13:14:11 EDT 2004
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
This translates, more or less, into fork safety for the following krb5
> 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.
More information about the krbdev