Unixの別のプロセスの環境変数を変更する方法はありますか?
-
03-07-2019 - |
質問
Unixでは、あるプロセスが別のプロセスの環境変数を変更する方法はありますか(それらはすべて同じユーザーによって実行されていると仮定しています)。一般的な解決策が最善ですが、そうでない場合、一方が他方の子である特定のケースについてはどうですか?
編集:gdb経由でどうですか?
解決
gdb経由:
(gdb) attach process_id
(gdb) call putenv ("env_var_name=env_var_value")
(gdb) detach
これは非常に厄介なハックであり、もちろんデバッグシナリオのコンテキストでのみ実行する必要があります。
他のヒント
おそらく技術的には実行できますが(他の回答を参照)、それは役に立たないかもしれません。
ほとんどのプログラムは、起動後にenv変数を外部から変更できないことを期待するため、ほとんどの場合、起動時に関心のある変数を読み取り、それに基づいて初期化します。したがって、プログラムがそれらを再読み取りすることはないため、後でそれらを変更しても違いはありません。
これを具体的な問題として投稿した場合は、おそらく別のアプローチを取る必要があります。好奇心からだけの場合:いい質問:-)。
実質的にはありません。十分な特権(ルート、またはその周辺)があり、/ dev / kmem(カーネルメモリ)の周りを突いて、プロセスの環境に変更を加えた場合、プロセスが実際に環境変数を再参照した場合(つまり、プロセスenv varのコピーをまだ取得しておらず、そのコピーだけを使用していませんでした)、そして、もしあなたが幸運で賢く、風が正しい方向に吹いていて、月の位相が正しいなら、おそらく、あなたは何かを達成するかもしれません。
クォーティングジェリーピーク:
老犬に新しいトリックを教えることはできません。
できることは、子プロセスの環境変数を起動前に変更することだけです。親プロセスのコピーを取得します。申し訳ありません。
http://www.unix.com.ua/orellyを参照してください。 /unix/upt/ch06_02.htm で詳細を確認してください。
/ procの使用に関する回答についてコメントするだけです。 Linuxでは/ procがサポートされていますが、動作しません。rootであっても / proc / $ {pid} / environ
ファイルを変更できません。 絶対に読み取り専用。
私はそれを行うためにかなり工夫された方法を考えることができ、それは任意のプロセスでは機能しません。
「char * getenv」を実装する独自の共有ライブラリを作成するとします。次に、「LD_PRELOAD」または「LD_LIBRARY_PATH」環境を設定します。 varsを使用して、両方のプロセスが共有ライブラリをプリロードして実行されるようにします。
この方法では、本質的に 'getenv'関数のコードを制御できます。その後、あらゆる種類の厄介なトリックを行うことができます。 「getenv」は、env varの代替値について外部設定ファイルまたはSHMセグメントを参照できます。または、要求された値で正規表現検索/置換を実行できます。または...
動的なリンカ(ld-linux.so)を書き換える以外に、(rootであっても)任意の実行中のプロセスに対してこれを行う簡単な方法は考えられません。
またはプロセスを取得して、新しいプロセスの構成ファイルを更新し、次のいずれかを実行します。
- 新しいプロセスでkill -HUPを実行して、更新された構成ファイルを再読み取りするか、
- プロセスが時々設定ファイルの更新をチェックするようにします。変更が見つかった場合は、構成ファイルを再読み取りします。
私が知る限りではない。実際には、IPCメソッド(共有メモリ、セマフォ、ソケットなど)の1つを呼び出すプロセス間で通信しようとしています。これらの方法のいずれかでデータを受け取ったら、環境変数を設定したり、他のアクションをより直接実行したりできます。
UNIXが/ procファイルシステムをサポートしている場合、envを読むのは簡単です-環境、コマンドライン、およびそのように所有しているプロセスの多くの他の属性を読むことができます。それを変える...さて、私は方法を考えることができますが、それは悪い考えです。
より一般的な場合...わかりませんが、移植可能な答えがあるとは思いません。
(編集:私の元の答えは、OPがenvを変更するのではなく、読むことを望んでいると仮定した)
UNIXはプロセス間通信でいっぱいです。ターゲットインスタンスにいくつかがあるかどうかを確認します。 Dbusは「デスクトップ」の標準になりつつあります。 IPC。
Dbus" sender"で awesome-client を使用してAwesomeウィンドウマネージャー内の環境変数を変更します。 luaコードの。
直接的な回答ではありませんが... 先日だけの[Windowsベースの]理論的根拠:-
...確かにサポートされていない方法、またはデバッガーの助けを借りて機能する方法がありますが、少なくとも別のプロセスのコマンドラインへのプログラムによるアクセスについてはサポートされていません。カーネルによって提供されるものはありません。 ...
ないということは、必要のない情報を追跡しないという原則の結果です。カーネルは、別のプロセスのコマンドラインを取得する必要はありません。
CreateProcess
関数に渡されたコマンドラインを受け取り、それをGetCommandLine
関数が取得できる場所にある、起動中のプロセスのアドレス空間にコピーします。プロセスが独自のコマンドラインにアクセスできるようになると、カーネルの役割が完了します。コマンドラインはプロセスのアドレススペースにコピーされるため、プロセスはコマンドラインを保持しているメモリに書き込み、変更することもあります。その場合、元のコマンドラインは永久に失われます。唯一の既知のコピーが上書きされました。
つまり、そのようなカーネル機能はすべて
- 実装が難しい
- 潜在的にセキュリティ上の懸念
ただし、最も可能性の高い理由は、単純にそのような施設の使用例が限られていることです。