Replies by Alan Macdonald for InterSystems Developer Community

Alan Macdonald · Sep 22, 2023

Thanks for the reply! I don't think it's permissions...

The app is running under a normal user, but created specifically for creating the environment for the app (so a non-system, unprivileged, userland user). Let's call it "[appuser]".

The drivers have been installed by the root user, are owned by root:root but are all 774, so executable by anyone.

sh-4.2$ ls -lAFhZ /opt/cache-odbc/bin/
-rwxrwxr-x root root ?                                cconnect.so*
-rwxrwxr-x root root ?                                cgateiw.so*
-rwxrwxr-x root root ?                                cgate.so*
-rwxrwxr-x root root ?                                cgateur64.so*
-rwxrwxr-x root root ?                                cgateu.so*
-rwxrwxr-x root root ?                                libcachedb.so*
-rwxrwxr-x root root ?                                libcacheodbc35.so*
-rwxrwxr-x root root ?                                libcacheodbciw35.so*
-rwxrwxr-x root root ?                                libcacheodbciw.so*
-rwxrwxr-x root root ?                                libcacheodbc.so*
-rwxrwxr-x root root ?                                libcacheodbcu35.so*
-rwxrwxr-x root root ?                                libcacheodbcur6435.so*
-rwxrwxr-x root root ?                                libcacheodbcur64.so*
-rwxrwxr-x root root ?                                libcacheodbcu.so*
-rwxrwxr-x root root ?                                libcacheodbcuw35.so*
-rwxrwxr-x root root ?                                libcacheodbcuw.so*
-r-xr-xr-x root root ?                                libiodbc.so*
-rwxrwxr-x root root ?                                libodbc.so*

There are no SELinux labels (all "?") , but on this Amazon Linux image, SELinux appears to be disabled (a bit terrifying, but means we can discount it as an issue!)

sh-4.2$ getsebool
getsebool:  SELinux is disabled

If I become the app user (with sudo su - [appuser]) and check the library for dependencies, I get:

[appuser]@ip-172-16-121-87 ~]$ ldd /opt/iris-odbc/bin/irisconnect.so
        linux-vdso.so.1 (0x00007ffc65ceb000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007f860e377000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f860df20000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f860dd1c000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f860db14000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f860d792000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f860d452000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f860d23c000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f860ce8f000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f860cc43000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f860c95f000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f860c75b000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f860c52a000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f860c315000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f860e5e6000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f860c0f7000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f860bee8000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f860bce4000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f860bace000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f860b8a7000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f860b643000)

Perhaps strangely, if I ask ldd to check dependencies for the Driver we're actually pointing at from the unixODBC driver manager, it doesn't mention irisconnect.so, but certainly doesn't throw any errors or missing dependencies.

[appuser]@ip-172-16-121-87 ~]$ ldd /opt/iris-odbc/bin/libirisodbcur6435.so
        linux-vdso.so.1 (0x00007ffc455fa000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f38debe7000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f38de865000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f38de525000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f38de178000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f38ddf62000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f38ddd44000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f38dedeb000)

So the app user appears to be able read and interrogate the various libraries.

I remain suspicious that, given the lack of an obvious dependency, and given the lack of a path in the trace output, perhaps we simply don't know where to find irisconnect.so, but as mentioned in the earlier post, any attempt to set $LD_LIBRARY_PATH or add a module to ld.so.conf.d seems to make the situation worse, not better.