HELP wanted: An async gensec

[Volker Lendecke]

On Fri, Jun 28, 2013 at 02:20:54PM +1000, 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. 
> 
> 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.
> 
> 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.  
> 
> 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). 
> 
> 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.  
> 
> Does anybody have the time to be able to help me with this?  

I'll be happy to assist with hints regarding tevent_req use.

With regards to libwbclient vs IRPC, what are your plans
regarding winbind3/4? I had already spent quite a while to
make libwbclient tevent_req based, but this turned out to
pull in more stuff than I would have hoped for. I came to
the conclusion that it's better to make libwbclient
completely thread-safe and then use fncall_send/recv to make
use of our pthreadpool implementation. Thread-safety would
also benefit other users of libwbclient.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de