mit-krb5 thread support -- fork safety

Nicolas Williams Nicolas.Williams at sun.com
Mon Apr 19 17:15:40 EDT 2004


On Mon, Apr 19, 2004 at 04:38:14PM -0400, Jeffrey Altman wrote:
> Nicolas Williams wrote:
> 
> >  Others could remain valid:
> >
> >   - krb5_principal
> >   - krb5_ccache
> >   - krb5_keytab
> >
> >
> I don't think a krb5_ccache object can be safely used after
> a fork.  The krb5_ccache object is opaque and may refer to
> data structures or kernel objects which are not inheritable.
> 
> Depending on how the krb5_keytab is implemented on a given
> system the same could be true. 
> 
> The only items which I believe are safe to maintain are the
> names of the principal, ccache and keytab.  The child process
> should be required to obtain new access to the objects in
> order to ensure that reference counting is properly maintained.

Ok.  But this implies that GSS-API credentials too may not survive
fork(), and so we should settle the GSS-API's semantics w.r.t. fork().

GSS-API names and contexts can be made to survive fork() with some
effort -- names because they are simple [attention Sam], contexts
because they can be exported/imported [though only one process can
continue to access any given security context].

Nico
-- 


More information about the krbdev mailing list