私はLD_LIBRARY_PATHを使ってアプリケーションの特定のユーザーライブラリのパスを設定します。私は、このアプリケーションに機能を設定した場合でも、Linuxの機能（setcap）がLD_LIBRARY_PATHを無効にしているようです
sudo setcap CAP_NET_BIND_SERVICE=eip myapplication
はその後LD_LIBRARY_PATHは無視しているようです。プログラムを起動すると、Linuxはある共有ライブラリを見つけることができないと不平を言う。
私は、拡張された権利を持つアプリケーションがハイジャックされるのを防ぐために何らかの保護が導入されていると思います。回避策はありますか？
はい、セキュリティ上の理由から無効です。
sudoためman pageは説明する：ほとんどのオペレーティングシステムでダイナミックリンカがsudoを含む setuid実行の環境から動的リンクを制御することができ 変数を削除することを
注意を。オペレーティングシステムによっては、 には、RLD *、DYLD *、LD_ 、LDR_、LIBPATH、SHLIB_PATH、および などが含まれます。これらのタイプの変数は、sudoが実行を開始する前に環境 から削除されます。したがって、 sudoがそれらを保存することはできません。
this link explainsとして、これを実行する実際のメカニズムはglibcにあります。 UIDがEUIDと一致しない場合（setuidプログラムの場合、sudoを含む）、すべての「安全でない環境変数」が削除されます。したがって、特権を昇格したプログラムは変更なしで実行されます。
これは非常にうまくいきますが、setcapはUIDまたはEUIDを変更しません。機能を追加します（ "昇格された権限"）。 – reinierpost
すでに他の回答に記載されているように、この動作が意図されています。あなた自身でアプリケーションをコンパイル（または少なくともリンク）することができれば、いくつかの回避策があります。その後、-Wl,-rpath <yourDynamicLibraryPath>をgccに、または-rpath <yourDynamicLibraryPath>をldに渡すことができ、実行時にはLD_LIBRARY_PATHを指定する必要はありません。
任意のエディタを使用してこのファイルを開く xyz.conf新しいファイル $ touchを作成するディレクトリ $cd /etc/ld.so.conf.d/ に行く $vi xyz.conf
追加：次のように
ありがとう、それは魅力のように動作します。 –
Linux上でこの問題を解決するには、このファイルのダイナミックライブラリのパス次のようにパスがある場合：
/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ 次のように、このファイルには3つの項目があるはずです： /home/xyz/libs1/ /home/xyz/libs2/
その後、このファイルを保存し、次のコマンドを実行します。 $ldconfig
上記のすべての操作は、rootログインから実行する必要があります。
rpathを設定するために、patchelfを使用して、コンパイルされていないELF共有ライブラリおよび/または実行可能ファイルを「修正」する方法もあります。 https://nixos.org/patchelf.html
ld.so.confは必ずしも確かではありません。実行しているものが正しくコンパイルされていればうまく動作します。私の場合、特別にパッケージ化されたベンダーのApache製品では、それほどコンパイルされませんでした。彼らはユニークな.soファイル名を使用していないため、よく使用されるいくつかの重要なライブラリを提供するRHELリポジトリのRPM 。だから、これがどのように使用されたのかを特定する唯一の選択肢でした。 ld.so.confをベンダーのlibパスにある共有オブジェクトに対して使用すると、システム全体でglibc共有ライブラリの失敗とともに、yumが含まれていたことが多くなりました。
https://bugzilla.redhat.com/show_bug.cgi?id=448594 – mpe