Re: Use of kdc_send_hook with gss_init_sec_context

On Sun, Feb 6, 2022 at 1:07 AM Stefan Metzmacher <[email protected]> wrote:
>
>
> Am 05.02.22 um 11:52 schrieb Isaac Boukris:
> > On Sat, Feb 5, 2022 at 9:56 AM Stefan Metzmacher <[email protected]> wrote:
> >>
> >>
> >> Am 04.02.22 um 19:34 schrieb Greg Hudson:
> >>> On 2/4/22 11:57 AM, Isaac Boukris wrote:
> >>>>>> Is there a way to use 'kdc_send_hook' with 'gss_init_sec_context'?
> >>>>>> If there isn't, can we add something like 'gsskrb5_set_krb5_context'?
> >>>
> >>> I've floated this idea before, as a way to bridge libkrb5 functionality
> >>> (such as krb5_init_context_profile()) and GSS.
> >>>
> >>> Nico dislikes the idea because he doesn't like anything that encourages
> >>> mechanism-specific code in GSS applications.  He tends to favor name
> >>> attributes as the extension point when possible.
> >>>
> >>> Sam has raised a more specific objection: if the context set by
> >>> gsskrb5_set_krb5_context() is per-thread (which is the easiest way to
> >>> get around contexts not being thread-safe), then it could be a source of
> >>> subtle bugs if someone creates a GSS object in one thread and gets
> >>> different behavior when they use it in another thread.
> >>>
> >>> I don't totally understand your use case.  If I read correctly, the
> >>> platform (wasm) requires the use of websockets rather than TCP or UDP.
> >>> So what code would register the send hook and GSS context?  Does every
> >>> application have to be modified in order to work with the platform?
> >>> That doesn't seem like a good long-term design compared to solving the
> >>> problem within libkrb5.
> >>
> >> I'd like to propose something similar to the send_to_realm
> >> plugins available in heimdal, see
> >> https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc_plugin.h
> >>
> >> This is what I'm trying to use in Samba soon,
> >> because it's too much work have everything working with just the _step() apis.
> >
> > Looking at send_to_realm() it doesn't seem much different than MIT's
> > kdc_send_hook(), so I wonder how you would make use of it for async
> > operations, since you need to provide the kdc reply synchronously upon
> > returning.
>
> We'd need a helper thread or helper process to run the
> gss/krb5 function in blocking mode and use socketpair to the main thread.
> the send_to_realm() would be like this:
>
>     sendto(socketpair, realm+req_buffer);
>     revcfrom(socketpair, rep_buffer);
>
> While the main thread can almost use the same async logic
> to transmit the buffers to the correct kdc as it does for the _step api
> case.
>
> My plan would be to use the _step() apis as much as possible
> and fallback to the more complex solution if needed.
>
> E.g. call gss_init_sec_context() with send_to_realm() rejecting any
> traffic if it happens and only in that case start to use a thread
> or helper process.

I realized after writing that gss_init_sec_context() can't be used
async without changing it to return eagain or something (aside from my
use case, with the asyncify magic).

> >> In order to get something working with existing MIT krb5 installations
> >> I had the crazy idea of having a locator plugin, which is registered globally.
> >> That plugin would return a single but unreachable (loopback) address
> >> and also registers a kdc_send_hook to the passed krb5_context (so it also
> >> able to inject it into the krb5_context hidden in the gssapi layer.
> >> The kdc_send_hook() acts like a send_to_realm hook by returning a hook_reply.
> >
> > Thanks for the hack, I might try it out as it seems simpler than the
> > current alternatives I have in mind. That said, with the web being the
> > single largest platform in today's ecosystem, I'd still hope for a
> > more straightforward way to build and use the krb5 libs on it.
>
> I think a real send_to_realm plugin would be better,
> but it will take quite some time to land in distributions.

Anything that'd work for gss would be great for me as well, for now
I'd use a simple local patch adding gsskrb5_set_krb5_context(), as I
build with "--disable-thread-support".
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev