<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 1, 2019 at 7:26 PM Sami Ketola <<a href="mailto:Sami.Ketola@open-xchange.com">Sami.Ketola@open-xchange.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>For secure applications LD_LIBRARY_PATH components
are ignored for non-secure directories.</div><div><br></div><div>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.</div></div></blockquote><div> </div><div>That's rather strange. </div><div>I too work with solaris ( and for sun in the past ) from sunos 4.1 onwards.</div><div><br></div><div>I had this previous installation working, with LD_LIBRARY_PATH configured, on solaris 10 u8 since 2014.</div><div><br></div><div>During this relativelly calm period I did a LiveUpgrade to latest solaris 10 ( u11 ) and the only application that stopped working is dovecot.</div><div>This mean that ( obviously ) solaris changed something on security.</div><div>No binary is setuid or setgid in dovecot dir:</div><div><br></div><div><div>ls -l /usr/local/dovecot/sbin/dovecot</div><div>-rwxr-xr-x   1 root     root      259452 Dec 29 14:59 /usr/local/dovecot/sbin/dovecot</div></div><div><br></div><div><div>root@puma find . -perm 4000<br></div><div>root@puma find . -perm 2000</div><div>root@puma find . -perm 1000</div></div><div><br></div><div>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.</div><div>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" ).</div><div><br></div><div>Thanks to all </div><div>Pigi</div></div></div></div></div>