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

[michael@stroeder.com]

william.b.clay@acm.org wrote:
> By localhost, I simply meant running the LDAP client I am developing on 
> the same host as slapd.  To test the same code on different client 
> hosts, the coded test URIs always specified the server's FQDN.

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 same tests over the same client code running on a different host 
> than slapd never got SEGFAULTs -- which I find curious given the nature 
> of that little bug. There must be some difference in OS memory 
> allocation logic applied in the two cases.

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?

> I recognize EXTERNAL may not be heavily used, although it's quite useful 
> in the environment I'm supporting.

Actually I'm heavily using SASL/EXTERNAL in almost all my customer setups and in
Ã?-DIR using either LDAPI:// with Unix Peer Credential passing or TLS with client
certs (e.g. for replication).

Therefore I appreciate every fix going into this. :-)

Ciao, Michael.