33

LD_LIBRARY_PATHアプリケーションの特定のユーザーライブラリのパスを設定するために使用します。しかし、このアプリケーションに機能を設定すると

sudo setcap CAP_NET_BIND_SERVICE=eip myapplication

その後、LD_LIBRARY_PATH無視されているようです。プログラムを起動すると、Linuxは特定の共有ライブラリが見つからないと文句を言います。

拡張された権限を持つアプリケーションが乗っ取られるのを防ぐために、何らかの保護が機能していると思います。回避策はありますか？

4

5 に答える 5

13

他の回答ですでに述べたように、この動作は意図されたものです。アプリケーションを自分でコンパイル（または少なくともリンク）できる場合は、何らかの回避策があります。-Wl,-rpath <yourDynamicLibraryPath>次に、gccまたはldに渡すことができ、実行時-rpath <yourDynamicLibraryPath>に指定する必要はまったくありませんLD_LIBRARY_PATH。

于 2012-08-14T15:15:05.983 に答える
11

Linuxでのこの問題の解決策は次のとおりです。

ディレクトリに移動し $cd /etc/ld.so.conf.d/ て新しいファイルを作成します$touchxyz.conf任意のエディタを使用してこのファイルを開きます $vi xyz.conf

パスが次の場合など、ダイナミックライブラリパスをこのファイルに1行ずつ追加します。

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/ この場合、このファイルには次の3つのエントリがあります。 /home/xyz/libs1/ /home/xyz/libs2/ /home/xyz/libs3/

次に、このファイルを保存して、次のコマンドを実行します。 $ldconfig

上記のすべての操作は、rootログインから実行する必要があります

于 2014-02-28T05:42:40.270 に答える
9

のマニュアルページは次のようにsudo説明しています。

ほとんどのオペレーティングシステムのダイナミックリンカは、sudoを含むsetuid実行可能ファイルの環境からダイナミックリンクを制御できる変数を削除することに注意してください。オペレーティングシステムによっては、RLD *、DYLD *、LD_ 、LDR_、LIBPATH、SHLIB_PATHなどが含まれる場合があります。これらのタイプの変数は、sudoが実行を開始する前に環境から削除されるため、sudoがそれらを保持することはできません。

このリンクで説明されているように、これを行うための実際のメカニズムはglibcにあります。UIDがEUIDと一致しない場合（をsetuid含むすべてのプログラムの場合sudo）、すべての「安全でない環境変数」が削除されます。したがって、昇格された特権を持つプログラムは変更なしで実行されます。

于 2012-08-10T20:02:48.483 に答える
4

はい、セキュリティ上の理由から無効になっています。

于 2012-04-18T17:57:58.230 に答える
2

考慮すべき代替策は、rpathを設定するためにpatchelfを使用して、コンパイルが不十分なELF共有ライブラリおよび/または実行可能ファイルを「修正」することです。 https://nixos.org/patchelf.html

ld.so.confは必ずしも確実な賭けではありません。実行しているものが適切にコンパイルされていれば機能します。私の場合、特定の特別にパッケージ化されたベンダーのapache製品では、コンパイルが非常に不十分でした。一意の.soファイル名を使用していなかったため、非常に重要な一般的に使用されるライブラリを提供するベースRHELリポジトリのRPMからの.soファイル名と競合していました。 。したがって、これが使用方法を分離する唯一のオプションでした。ベンダーのlibパス内のこれらの共有オブジェクトに対してld.so.confを使用すると、yumを含む多くのものが吹き飛ばされ、システム全体でglibc共有ライブラリの障害が発生します。

于 2015-07-10T05:47:00.320 に答える