Les capacités Linux (setcap) semblent désactiver le chemin de la bibliothèque LD

Comme déjà indiqué dans d'autres réponses, ce comportement est destiné. Il existe une sorte de solution de contournement si vous pouvez compiler (ou au moins lier) l'application vous-même. Ensuite, vous pouvez passer -Wl,-rpath <yourDynamicLibraryPath> à gcc ou -rpath <yourDynamicLibraryPath> à ld et vous n'aurez pas du tout à spécifier LD_LIBRARY_PATH lors de l'exécution.

La page de manuel pour sudo explique:

Notez que l'éditeur de liens dynamique sur la plupart des systèmes d'exploitation les variables qui peuvent contrôler la liaison dynamique de l'environnement de exécutables setuid, y compris sudo. Selon le système d'exploitation cela peut inclure RLD*, DYLD *, LD_ , LDR_, LIBPATH, SHLIB_PATH, et les autres. Ces types de variables sont supprimés de l'environnement avant que sudo ne commence même l'exécution et, en tant que tel, ce n'est pas le cas possible pour sudo pour les préserver.

Comme ce lien explique , le mécanisme réel pour le faire est dans la glibc. Si L'UID ne correspond pas à L'EUID (ce qui est le cas pour tout programme setuid, y compris sudo), Toutes les "variables d'environnement non sécurisées" sont supprimées. Ainsi, un programme avec des privilèges élevés s'exécute sans altération.

La solution à ce problème sous linux est la suivante:

Aller au répertoire $cd /etc/ld.so.conf.d/ créer un nouveau fichier $ toucher xyz.conf ouvrez ce fichier en utilisant n'importe quel éditeur $vi xyz.conf

Ajoutez le chemin de votre bibliothèque dynamique dans ce fichier ligne par ligne, par exemple si votre chemin est le suivant:

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ ensuite, il devrait y avoir trois entrées dans ce fichier comme suit: /home/xyz/libs1/ /home/xyz/libs2/ /home/xyz/libs3/

Ensuite, enregistrez ce fichier et exécutez la commande suivante: $ldconfig

Tous les éléments mentionnés ci-dessus l'opération doit être effectuée à partir de la connexion root

Une alternative à considérer est de "corriger" une bibliothèque partagée ELF mal compilée et/ou exécutable en utilisant patchelf pour définir le rpath. https://nixos.org/patchelf.html

Ld. so. conf n'est pas toujours le pari sûr. Cela fonctionnera si tout ce que vous exécutez a été compilé correctement. Dans mon cas, avec le produit apache d'un fournisseur spécialement empaqueté, il a été compilé si mal: ils n'ont même pas utilisé de noms de fichiers uniques .so, ils sont donc en conflit avec les noms de fichiers. so Des RPM dans le dépôts de base RHEL qui ont fourni des bibliothèques assez critiques couramment utilisées. C'était donc la seule option pour isoler la façon dont ils étaient utilisés. L'utilisation de ld. so. conf contre ces objets partagés dans le chemin lib du fournisseur aurait emporté beaucoup de choses, y compris yum, ainsi que les échecs de la bibliothèque partagée glibc, à l'échelle du système.