Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT

[william.b.clay@acm.org]

> So you're using TLS client cert and SASL/EXTERNAL to a hostname (also in ther
> server cert) but where the IP address of the hostname is directly routed through
> 127.0.0.1?

The slapd log of my same-host tests confirms they in fact used the IPv4 
loopback address, 127.0.0.1, even though the bind URI specified the FQDN.

> Not sure but the difference is the client IP address. If the client can reach
> slapd through 127.0.0.1 the client's IP address is also 127.0.0.1 which could
> make a difference in the SASL client handling. Anyone said hostname
> canonicalization? Does setting sasl-host <fqdn> make a difference?

The ~/.ldaprc used by the client in these tests contained "TLS_REQCERT 
none", so a mismatch between the server's FQDN and the peer address 
actually used would not have been detected.  Another difference would be 
"ping-pong" memory allocation between client and server.  Even though 
different processes, they may allocate from the same pool.  With the 
client running on a different host in other tests, slapd would not be 
competing with other processes in a predictable, repeatable fashion 
(slapd SEGFAULTs were 100% repeatable for specific sequences of EXTERNAL 
binds, but only with client and server on the same host).