Re: (ITS#6257) libldap: getopt flag to return the SASL username

[masarati@aero.polimi.it]

>> 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.