Re: SASL authentication

Anton Bobrov wrote:
> 
> Xu, Qiang (FXSGSC) wrote:
> 
>> Unfortunately, our printer is an embedded system, and the OS in it is 
>> a simplied Wind River Linux system. There is no "truss" command 
>> available in it. Even the command "env" is not available. So I don't 
>> know how to set this SASL_PATH into the environment. 
> 
> surely it has something like setenv(3). if so can you try that ?
> 
>> However, when I use "ldd" to the library, it displays:
>> ====================================
>> mbc80:/opt/nc/lib <207> ldd libsasl2.so
>>         linux-gate.so.1 =>  (0xffffe000)
>>         libdl.so.2 => /lib/libdl.so.2 (0xb7eed000)
>>         libresolv.so.2 => /lib/libresolv.so.2 (0xb7edb000)
>>         libc.so.6 => /lib/libc.so.6 (0xb7dca000)
>>         /lib/ld-linux.so.2 (0x80000000)
>> ====================================
>> Shouldn't the libraries for plugins also appear in the list?
> 
> i dont think any of them are explicitly linked. afaik they get
> loaded dynamically by libSASL based on mech name requested. it
> is kinda the whole point of having them as plugins really.

Correct.  They get loaded dynamically.  When you do sasl_client_init() 
it will call the getpath callback in the provided sasl_callbacks list. 
(NOTE that mozldap does not allow you to pass in or otherwise override 
the getpath callback - it should - as well as allow you to 
provide/override the other sasl_callbacks).  The fallback if there is no 
getpath is to look in SASL_PATH or the path built into libsasl2.so when 
it was compiled.  It will then assume every shared lib in that directory 
is a sasl mech plugin and attempt to dynamically load it.