Getting rid of smb_krb5_send_and_recv_func()

Simo simo at samba.org
Mon May 5 18:23:16 MDT 2014


On Tue, 2014-05-06 at 10:52 +1200, Andrew Bartlett 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_krb5_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.  

Why would a process fail to talk to itself w/o these functions ?

> Please do not remove this without my explicit ACK. 

It would be better you explained better the use of these functions so
people can determine how to deal with them, if you do not explain
exactly how things works how can A) people determine what is needed for
a change and B) how do you judge when it is ok to remove them ?

Simo.




More information about the samba-technical mailing list