Re: Several problems on Solaris10
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
On 02 January 2019 at 10:36 Pierluigi Frullani <pierluigi.frullani@gmail.com> wrote:
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
Dovecot master process does some fair amount of setgid/setuid, as do the actual binaries, which might affect the linker's behaviour too.
Aki
participants (2)
-
Aki Tuomi
-
Pierluigi Frullani