Re: GSS-APIv3 sketch

Volker Lendecke <Volker.Lendecke@SerNet.DE> Wed, 11 November 2009 23:06 UTC

Return-Path: <Volker.Lendecke@SerNet.DE>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2F933A6929 for <>; Wed, 11 Nov 2009 15:06:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IkqagPONgydo for <>; Wed, 11 Nov 2009 15:06:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E7A5F3A68FC for <>; Wed, 11 Nov 2009 15:06:37 -0800 (PST)
Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1N8MHG-0003bQ-5S; Thu, 12 Nov 2009 00:07:02 +0100
Received: by intern.SerNet.DE id 1N8MHF-004jYm-T7; Thu, 12 Nov 2009 00:07:02 +0100
Received: by intern.SerNet.DE id 1N8MHF-004jYU-K6; Thu, 12 Nov 2009 00:07:01 +0100
Date: Thu, 12 Nov 2009 00:08:50 +0100
From: Volker Lendecke <Volker.Lendecke@SerNet.DE>
To: Andrew Bartlett <>
Subject: Re: GSS-APIv3 sketch
References: <20091111181140.GC10501@Sun.COM> <> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.18 (2008-05-17)
Message-Id: <E1N8MHF-004jYm-T7@intern.SerNet.DE>
Organization: SerNet GmbH, Goettingen, Germany
Cc: "" <>, vl <>, Love Hörnquist Åstrand <>, Nicolas Williams <>
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Volker.Lendecke@SerNet.DE
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Nov 2009 23:06:40 -0000

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

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

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.