Getting rid of smb_krb5_send_and_recv_func()

[Andreas Schneider]

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?



	-- andreas


-- 
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at samba.org
www.samba.org