Las capacidades de Linux (setcap) parecen deshabilitar la RUTA de la BIBLIOTECA LD

Como ya se ha dicho en otras respuestas, este comportamiento es la intención. Hay algún tipo de solución alternativa si puede compilar (o al menos vincular) la aplicación usted mismo. Luego puede pasar -Wl,-rpath <yourDynamicLibraryPath> a gcc o -rpath <yourDynamicLibraryPath> a ld y no tendrá que especificar LD_LIBRARY_PATH en absoluto en la ejecución.

La página de manual para sudo explica:

Tenga en cuenta que el enlazador dinámico en la mayoría de los sistemas operativos eliminará variables que pueden controlar la vinculación dinámica desde el entorno de ejecutables setuid, incluyendo sudo. Dependiendo del sistema operativo esto puede incluir RLD*, DYLD*, LD_, LDR_, LIBPATH, SHLIB_PATH, y otros. Este tipo de variables se eliminan del entorno antes de que sudo incluso comience la ejecución y, como tal, no es posible sudo para preservarlos.

Como este enlace explica, el mecanismo real para hacer esto está en glibc. Si el UID no coincide con el EUID (que es el caso de cualquier programa setuid, incluido sudo), se eliminan todas las "variables de entorno no seguras". Por lo tanto, un programa con privilegios elevados se ejecuta sin alteración.

La solución a este problema en linux es la siguiente:

Ir al directorio $cd /etc/ld.so.conf.d/ crear un nuevo archivo touch tocar xyz.conf abra este archivo usando cualquier editor $vi xyz.conf

Agregue la ruta de su biblioteca dinámica en este archivo línea por línea para, por ejemplo, si su ruta es la siguiente:

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ entonces debe haber tres entradas en este archivo de la siguiente manera: /home/xyz/libs1/ /home/xyz/libs2/ /home/xyz/libs3/

Luego guarde este archivo y ejecute el siguiente comando: $ldconfig

Todo lo anterior la operación debe realizarse desde el inicio de sesión root

Una alternativa a considerar es "corregir" una biblioteca compartida ELF mal compilada y/o ejecutable usando patchelf para establecer la ruta de acceso. https://nixos.org/patchelf.html

Ld.so.conf no siempre es la apuesta segura. Funcionará si lo que esté ejecutando se compiló correctamente. En mi caso, con el producto apache de un proveedor especialmente empaquetado en particular, se compiló tan mal: Ni siquiera usaron nombres de archivo unique .so, por lo que entraron en conflicto con los nombres de archivo. so de RPMs en el repositorios RHEL base que proporcionaron algunas bibliotecas bastante críticas de uso común. Así que esta era la única opción para aislar cómo se usaban. El uso de ld. so.conf contra esos objetos compartidos en la ruta de acceso de la librería del proveedor habría eliminado muchas cosas, que incluían yum, junto con fallas en la biblioteca compartida de glibc, en todo el sistema.