Re: GSS-APIv3 sketch

[Volker Lendecke <[e-mail]>]

On Thu, Nov 12, 2009 at 09:59:26AM +1100, Andrew Bartlett wrote:
> > The same approach of associating callbacks with the call context works
> > for prompter callbacks for dealing with initial credential acquisition.
> 
> I'm hoping that Volker or Metze (CC'ed async experts on the Samba Team)
> can fill out some more detail, but I'll start by nothing that anything
> that requires threads, or causes the library to start threads is a
> non-starter for Samba.  
> 
> Creating threads behind the applications' back is a really bad idea. 
> 
> We really need a proper state machine, with integration available into
> our event library (or any other the event library the caller
> provides).  
> 
> As to portability, if no event lib is provided by the caller, then just
> block like GSSAPI does at the moment.  

Just to confirm: Samba and probably other applications
really need an async gensec without threads. I've very
recently seen a talk by a SUN engineer talking about doing
threads behind an app's back. This really, really nasty
stuff.

For a possible model how to do the async API, I would
suggest looking at the avahi libraries:

http://avahi.org/download/doxygen/struct_avahi_poll.html

Writing an async state machine is definitely a non-trivial
task, but it is possible given the right infrastructure. In
Samba, it has taken us several iterations to come up with
something that makes state machines relatively easy to do.
Unfortunately it heavily depends on our hierarchical memory
allocator called talloc. Without such a thing, memory
management can very quickly become a real nightmare.

Volker