HELP wanted: An async gensec

[Simo]

On 06/28/2013 12:20 AM, Andrew Bartlett wrote:
> I know a large number of folks of the team have been long frustrated by
> the lack of async in gensec.
>
> My issue isn't a lack of desire to do this, but that because of the
> different work I've been doing in Samba, that I have real difficulty
> getting my head around the tevent patterns, particularly in this complex
> area.  I also wasn't sure how to do this without having an async gssapi
> lib to build on.

We could get faster results by simply using gssapi directly in threads 
with a
thin tevent wrapper around. Given gssapi *is* threads safe unlike most 
of our
other code this would be possible with minimal use of locks around whatever
internal callback we need to use for some cases.

> What I'm hoping for is someone to work closely with me as we implement
> this.
>
> What I plan is this much:
>
> First, I want to make 'samba' (the binary) and anything else using the
> machine account password use a common FILE based ccache, in the private
> dir.  The idea here is that files can be safely shared between
> processes, and this will avoid most calls to the KDC, as most of the
> time there is already a ticket for the service we want to contact.

+1 I wanted to do this for ages, and also had preliminary patches for the
old samba3 code to do that, but never had the time to fix all the 
dependencies.

> Then, I want, when a file based ccache is in use:
>
>   - To fork (like source4/libcli/resolv/dns_ex.c does) and have the child
> do the talking to the KDC, both for the initial ticket work, and for the
> GSS calls.
>
>   - When doing a fork() for the GSS calls, I would return the gss state
> via gss_export_sec_context() to the calling process.

You could take a look at gssproxy for this.

> If a MEMORY based ccache is in use, we would do blocking calls instead,
> but NOT pass an event context in to the send_to_kdc routines - they
> would create a new one and block.  This shouldn't impact on the 'samba'
> binary single-process mode, as it uses the machine account password.
> (This should therefore remove the most challenging nested event loop in
> Samba).

Isn't send_to_kdc doing networks calls ?

> Finally, for the server-side NTLMSSP code, I would like the call to
> winbind to be changed from using libwbclient to using IRPC, and to build
> on top of that already tevent-enabled library, to allow async NTLM
> logins in the SMB server.

Again a NTLM implementation in gssapi would allow you to use threads and
avoid most of the complexity.

> Does anybody have the time to be able to help me with this?
>

I do not have time right now, but I might help with an implementation that
leans toward using gssapi and threads.

Simo.