HELP wanted: An async gensec

[Volker Lendecke]

On Fri, Jun 28, 2013 at 09:40:33PM +1000, Andrew Bartlett wrote:
> 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?

https://tevent.samba.org/group__tevent__request.html

has some idea of introduction. There's a ton of examples
around in our code. In source3/winbind/wb_seqnum.c you can
find a very simple example that just maps some parameters,
wrapping one async call (dcerpc_wbint_QuerySequenceNumber)
into another one (wb_seqnum). A lot of the conventions are
laid down in such an example. From there you can for example
take a look at wb_lookupname.c, which implements a
potentially two-step async sequence of events. It's always
the same: Define a operation_state struct (even if it's just
a dummy one), implement _send and _recv functions. If you
have to delegate to another async operation, do it with a
subreq and a _done callback. In the tevent_req world, never
ever mess with the tevent_add_fd or tevent_add_timed
functions directly, there's always wrappers for those
around. For socket write we have writev_send/recv, for
socket read we have read_packet_send/recv. For timeouts we
have tevent_req_set_endtime and tevent_wakeup_send/recv.

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

That's a function that does a fork, calls a function in the
child where the parent just waits for the function to
finish? The result is passed in a file? Attached find a
completely hacked-up non-compiled skeleton that I would
start from. Fill in the kinit-specific pieces :-)

> 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 think the specific transport mechanism beween the gensec
server part and winbind is not really what should block us
here. I know that the winbind pipe protocol is ugly beyond
repair, but I think for most purposes the authenticateuserex
operation should do what we need. Getting that threadsafe
might be an easier path than putting irpc into
source3/winbind, but I have not looked closely enough into
irpc and what it would exactly mean implementation-wise.

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

We have to get that out of the Samba world anyway, that
interface being private is a mistake IMHO. I know that other
projects that now use the venerable ntlm_auth utility could
probably greatly benefit from a threadsafe API call that
does the whole spnego business with winbind. Doing the
samlogon piece only first might be a first step.

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