On a somewhat related issue, I note that LDAP_OPT_X_SASL_MECHLIST returns a pointer to an array of chars that apparently cannot be mucked with.
Assuming my understanding is correct, I wonder if this behavior is desirable or not, given the fact that if another mech is added, e.g. by adding a dynamic module, I expect this list to change.
These are SASL mechs with the plugin modules. Right?
From an operational standpoint: If a SASL plugin module for a mech was added I
think it's acceptable that a software which queries this option is restarted before this SASL mech is known to the software. Probably one has to add additional configuration for this SASL mech.
Now the question is what happens if a SASL plugin module is removed and the software trys to use the removed SASL mech. Clearly removing plugin modules in a running system is asking for trouble anyway...
Having said this I would not care too much about this list going to change...
My concern was not from an operational point of view: the simple concept of having a library dynamically loading something that could no longer be present is calling for trouble, unless handled appropriately, and probably there is no way to do it safely as one could always remove a .so while it's in use (although I guess on any decent system the object will be cached or loaded somewhere until it's in use).
My concern is about the char* array returned by that call: if for any reason the library decides to refresh it, but the caller of ldap_get_option() is still holding a pointer to that array, this calls for pointing to freed memory and things like that, as far as I understand. For this reason, returning a copy sounds wiser. Whether the contents of that copy is valid or not, namely the related mechanism is available or not, that's an entirely different issue.
p.