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