On Tue, Jan 1, 2019 at 7:26 PM Sami Ketola <Sami.Ketola@open-xchange.com> wrote:

Believe me it does. I used to work for Sun Microsystems for 14 years in Solaris support and sustaining and I can guarantee you that it does.

You problem is that Solaris has concept of Secure Runtime Linker, and for trusted applications most of LD_CONFIG and LD_LIBRARY_PATH is ignored for security reasons.

For secure applications LD_LIBRARY_PATH components are ignored for non-secure directories.

Your dovecot is probably setuid or setgid and considered as secure application and secure runtime linker rules are triggered for it. Then /usr/local is completely ignored from LD_LIBRARY_PATH.

That's rather strange.

I too work with solaris ( and for sun in the past ) from sunos 4.1 onwards.

I had this previous installation working, with LD_LIBRARY_PATH configured, on solaris 10 u8 since 2014.

During this relativelly calm period I did a LiveUpgrade to latest solaris 10 ( u11 ) and the only application that stopped working is dovecot.

This mean that ( obviously ) solaris changed something on security.

No binary is setuid or setgid in dovecot dir:

ls -l /usr/local/dovecot/sbin/dovecot

-rwxr-xr-x 1 root root 259452 Dec 29 14:59 /usr/local/dovecot/sbin/dovecot

root@puma find . -perm 4000

root@puma find . -perm 2000

root@puma find . -perm 1000

but yes, I agree that eventually the SRL stuffs could make them job. Probably is not tied to the setuid/setgid but with the fork of a binary from inside another one with the LD_LIBRARY_PATH in use.

Thus the option is ( could be ) to use the R[UN]PATH feature or the wrapper with the new LD_LIBRARY_PATH ( as I'm doing now altough less secure ) or recompile with the -R option passed to linker, as suggested by James ( and verified to be working at least with the "dump" ).

Thanks to all

Pigi