1

I have a very strange problem on my Synology DS220+ NAS. (Kernel 4.4.59+, x86_64 GNU/Linux, synology_geminilake_220+)

dovecot, installed via opkg from Entware, has been running since years on my NAS. And suddenly when connecting securely via IMAP, I get an error in the logfile:

Nov 06 00:59:51 imap-login: Error: Failed to initialize SSL server context: Can't load SSL certificate (ssl_cert setting): error:12800067:DSO support routines::could not load the shared library: filename(libz.so): libz.so: cannot open shared object file: No such file or directory, error:12800067:DSO support routines::could not load the shared library: user=<>, rip=x.x.x.x(puplic-ip), lip=192.168.1.111, session=<o4eBiHAJQozCYLu3>
Nov 06 00:59:51 imap-login: Info: Disconnected: TLS initialization failed. (no auth attempts in 0 secs): user=<>, rip=x.x.x.x(=puplic-ip), lip=192.168.1.111, session=<o4eBiHAJQozCYLu3>

I tried to reinstall dovecat and zlib to no avail. So I started analysing the problem and now I know, that dovecot thinks it can't find the /opt/bin/libz.so shared zlib library. But the file exists!

I tried to strace dovecot (with child-processes, else the following lines would have not appeared):

14836 openat(AT_FDCWD, "/opt/lib/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/opt/lib/dovecot/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/opt/lib/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/opt/lib/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/opt/lib/dovecot/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/opt/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/usr/lib/tls/x86_64/x86_64/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 stat("/usr/lib/tls/x86_64/x86_64", 0x7ffe27868180) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/usr/lib/tls/x86_64/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 stat("/usr/lib/tls/x86_64", 0x7ffe27868180) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/usr/lib/tls/x86_64/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 stat("/usr/lib/tls/x86_64", 0x7ffe27868180) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/usr/lib/tls/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 stat("/usr/lib/tls", 0x7ffe27868180) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/usr/lib/x86_64/x86_64/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 stat("/usr/lib/x86_64/x86_64", 0x7ffe27868180) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/usr/lib/x86_64/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 stat("/usr/lib/x86_64", 0x7ffe27868180) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/usr/lib/x86_64/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 stat("/usr/lib/x86_64", 0x7ffe27868180) = -1 ENOENT (No such file or directory)
14836 openat(AT_FDCWD, "/usr/lib/libz.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
14836 stat("/usr/lib", 0x7ffe27868180)  = -1 ENOENT (No such file or directory)

So the system really thinks, that /opt/lib/libz.so doesn't exist. The permissions on the (symlinked) file are set to 644 (but I tried 777 too) and the user and group is root:root. dovecot is running as root.

ldd /opt/sbin/dovecot
        linux-vdso.so.1 (0x00007fffc18f5000)
        libcap.so.2 => /opt/lib/libcap.so.2 (0x00007f6a1faad000)
        libdovecot.so.0 => /opt/lib/dovecot/libdovecot.so.0 (0x00007f6a1f8da000)
        libssp.so.0 => /opt/lib/libssp.so.0 (0x00007f6a1f8d5000)
        libc.so.6 => /opt/lib/libc.so.6 (0x00007f6a1f721000)
        libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x00007f6a1f707000)
        libiconv.so.2 => /opt/lib/libiconv.so.2 (0x00007f6a1f621000)
        libdl.so.2 => /opt/lib/libdl.so.2 (0x00007f6a1f61a000)
        /opt/lib/ld-linux-x86-64.so.2 (0x00005650ac854000)

file /opt/sbin/dovecot
        /opt/sbin/dovecot: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /opt/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped
ldd /opt/lib/libz.so
        linux-vdso.so.1 (0x00007ffdf4899000)
        libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x00007f2acc4bb000)
        libc.so.6 => /opt/lib/libc.so.6 (0x00007f2acc307000)
        /opt/lib/ld-linux-x86-64.so.2 (0x0000560240cf2000)
file /opt/lib/libz.so
        /opt/lib/libz.so: symbolic link to libz.so.1
file /opt/lib/libz.so.1
        /opt/lib/libz.so.1: symbolic link to libz.so.1.2.13
file /opt/lib/libz.so.1.2.13
        /opt/lib/libz.so.1.2.13: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

/opt is a symlink to /volume1/@entware as is usual with Entware installations on synology devices.

Why does dovecot not find the library in /opt/lib/libz.so? And apparently this is no problem of dovecat as strace shows, that even the syscall "openat" doesn't see the file, although it exists and I can see it from the console!? (BTW. it finds other libraries in /opt/lib/ and in /opt/lib/dovecot for example)

1
  • I'd start with looking at /etc/ssl/openssl.cnf. (you can also try to rename it). Maybe som openssl update made something incompatible.
    – stoney
    Nov 6, 2023 at 9:52

1 Answer 1

1

OK, after hours and hours of searching I found the reason for this problem:

dovecot forks (clones) imap-login process and chroots it into /opt/var/run/dovecot/login
This is the only folder the process can see then, and there is no libz.so anywhere in this folder, but only the login sockets.

I copied libz.so.1.2.13 to /opt/var/run/dovecot/login/opt/lib/libz.so (no symlink!) and since then it's working again.

Maybe someone could shed some light on this nevertheless as I don't understand why it behaves like that, even though the documentation states ...

The login processes don’t need to be able to do anything else than let the user log in, so they can run in highly restricted environment. By default they are run as a non-privileged dovenull user chrooted into a non-writable directory containing only authentication UNIX sockets. Login processes also handle proxying the SSL and TLS connections even after the user has logged in. This way all the SSL code runs in the same restricted environment, which means that a security hole in the SSL library gives the attacker access only to the restricted chroot, rather than possibly all the users’ mails.

... it doesn't work as the chroot denies access to the zlib library, which is needed for TLS. I guess I should have found many instructions and threads and blog articles about this, if it was usual behaviour of dovecot and chroot, but not a single info to be found.

So in my opinion there is still something messed up with my installation, but it's running securely also if the libz.so is in the chrooted directory, so I will now stop investigating.

1
  • My underlying question would be to ask why this behaviour started manifesting only recently Nov 7, 2023 at 8:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .