Getting rid of smb_krb5_send_and_recv_func()

[Andrew Bartlett]

On Tue, 2014-05-06 at 10:03 +0200, Andreas Schneider wrote:
> On Tuesday 06 May 2014 19:48:33 Andrew Bartlett wrote:
> > On Tue, 2014-05-06 at 08:25 +0200, Andreas Schneider wrote:
> > > On Tuesday 06 May 2014 10:52:00 you wrote:
> > > > On Mon, 2014-05-05 at 09:32 +0200, Andreas Schneider wrote:
> > > > > On Thursday 01 May 2014 09:31:50 Andrew Bartlett wrote:
> > > > > > On Wed, 2014-04-30 at 11:54 +0200, Andreas Schneider wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > with Andrew his patches and the preloadable socket_wrapper we're
> > > > > > > now
> > > > > > > able
> > > > > > > to get rid of smb_krb5_send_and_recv_func().
> > > > > > > 
> > > > > > > I've prepared a patchset here:
> > > > > > > 
> > > > > > > https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/smb
> > > > > > > _krb
> > > > > > > 5_se
> > > > > > > nd_and_recv_func
> > > > > > > 
> > > > > > > 
> > > > > > > A local 'make test' completed successfully.
> > > > > > 
> > > > > > My main concern is that this implies that we are backing down from
> > > > > > Kerberos due to it failing, rather than actually handling this
> > > > > > properly.
> > > > > 
> > > > > I don't really get what you want to explain to me. For me this code
> > > > > looks
> > > > > like it has been created so that heimdal works with socket_wrapper.
> > > > > 
> > > > > > That is, I think we fall into the KDC not found case, and fall back
> > > > > > to
> > > > > > NTLM, when Samba is operating in single process mode.
> > > > > 
> > > > > If we remove this function then heimdal will take care of sending the
> > > > > packet. doesn't it?
> > > > > 
> > > > > Can you please explain this in more details so that Günther and I
> > > > > understand the purpose of these functions.
> > > > 
> > > > It has three purposes:
> > > > 
> > > > To use socket_wrapper, and to use our name resolution, and to use our
> > > > event loop, so a single-process mode server can talk to itself.  You
> > > > handled the first, perhaps the second and not the third.
> > > 
> > > nss_wrapper does name resolution and this works even with system
> > > libraries!
> > > For more details read: https://lwn.net/Articles/594863/
> > 
> > Yes, but so far we have not removed the dns_host_file as far as I can
> > see, and does nss_wrapper handle the SRV records and do real DNS lookups
> > to emulated DNS servers?
> 
> If you add them as aliases to the entry it will find them. I'm not sure if it 
> will fully work.
> 
> What we should work on is to support NSS modules for name resolution (DNS 
> lookups in NSS is a module, libnss_dns.so.2). So either we can load the 
> libnss_dns.so.2 module and have a resolv.conf which points to the Samba DNS 
> server or we write our own module.
> 
> This would allow to test our DNS implementation and simplify much more things.
>  
> > As I mention at
> > https://lists.samba.org/archive/samba-technical/2013-November/095966.html
> > I need this for the multi-domain stuff to work in 'make test'.
> > 
> > > So this leaves the event loop. Why does it need to use the Samba event
> > > loop?
> > When 'samba' is run as a single process, some aspects of the AD DC
> > (dreplsrv in particular) will need to ask for tickets from the KDC,
> > implemented in the same process.  Unless it uses the same event loop, it
> > would block on the read() waiting for a reply, because nothing will
> > allow the KDC to run.
> 
> So as we start a separate MIT KDC process, it is likely we will not run into 
> this issue.
> 
> > > > Please do not remove this without my explicit ACK.
> > > 
> > > We're trying to port Samba 4 to MIT Kerberos and are trying to understand
> > > why we do certain things. Please go into more details so we can
> > > understand why it was done this way.
> > 
> > As you won't run the AD DC in a true single process, you probably don't
> > need it.
> 
> Ok, thanks.
> 
> > However, this moment where we have interest in making this work properly
> > is a great opportunity to fix this properly.  What we need is a fork or
> > threads based async handler for gssapi and kerberos, so that the work
> > being done elsewhere to make gensec async can work for the gssapi
> > client.  I need someone confident with tevent and async work (that is,
> > not me) to take this part on.  This too will remove the need for the
> > event loop inside libkrb5, because it would instead loop at the gensec
> > caller or above, plus become async and non-blocking etc :-).
> 
> Will you be available next week for discussion when we are at SambaXP?

The timezones will be a challenge, but I'll see what I can do.  It is an
important chance to set some direction for Samba.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba