HELP wanted: An async gensec

[Andrew Bartlett]

On Fri, 2013-06-28 at 11:27 +0200, Volker Lendecke wrote:
> 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.

Thanks.  I guess I just need to start somewhere - any chance of helping
me out with some template patterns I could then fill in with the more
complex details?

Even just getting the appropriate parts of and callers to
kinit_to_ccache (not even part of gensec) async would make a big
difference I think. 

> With regards to libwbclient vs IRPC, what are your plans
> regarding winbind3/4? 

I wrote earlier about my plans
(https://lists.samba.org/archive/samba-technical/2013-May/092221.html),
but in short I was thinking that both for this and to merge the parts of
winbind4 that are built around IRPC, that it would be useful to have
winbind3 answer IRPC requests, including SamLogon. 

I would love to get some further comment on the things I wrote about
then.  Adding in these ideas around an async gensec, it seems even more
useful to have winbind3 answer IRPC.

> 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.

My thought is that for the complex, essentially private (return)
structures that NTLM authentication has to transact via winbind, that
IRPC would suit that particular use case well, and would allow us to
make this stuff async with an existing infrastructure. 

But I'm not yet fixated on a particular implementation approach, as long
as we can make some progress on our common goals. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org