Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT
> 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
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).