2

プログラムを作成し、それを Gtk+ で構築された gui と統合しようとしています。ただし、GUI によって呼び出される exe には setuid ビットが設定されています。ただし、gtk では、この exe を gtk コミュニティの指定どおりに実行することはできません。しかし、別のヘルパー プログラムとすべてを作成する必要があると彼らは言います。それが何を意味するのか本当にわかりません。この問題を克服する方法を教えてください。私は本当に即時の解決策が必要です。

4

3 に答える 3

4

最初の質問: プログラムが setuid になっているのはなぜですか? setuid プログラムを書くことは、自称 Linux 初心者がプレイすべきゲームではありません。彼らは危険です。それらは便利です - 誤解しないでください。しかし、それらは危険であり、安全に書き込むことは困難です。

GTK+ プロジェクトは、「 GTK+ - Using setuid 」で、setuid プログラムに関する見解を非常に率直に述べています。彼らは理由を挙げます - 良いものです。問題を回避する方法を示します。

GTK+ チームの意見では、グラフィカル ユーザー インターフェイスを備えた setuid プログラムを記述する唯一の正しい方法は、パイプなどのメカニズムを介して非 setuid グラフィカル ユーザー インターフェイスと通信し、入力を考慮する setuid バックエンドを持つことです。それは信頼できないと受け取られます。

ヘルパー プログラムを作成することになっているので、例を探しましたか? 与えられている可能性が高いです。あなたのプログラム自体は GUI アプリケーションですか?

ルート権限が必要です [...] いくつかの周辺機器を開き、それらのメモリで利用可能なデータを読み取り、それらを閉じます...これはルート権限なしでは実行できません...また、読み取られたデータは次を使用して同時に処理および表示されますGTK。

したがって、これはまさに GTK+ チームが説明している種類のシナリオです。GUI によって起動され、パイプや Unix ドメイン ソケット、または同様の手法によって接続される小さな setuid ルート プログラムが必要です。

周辺機器からのデータが必要な場合、メイン アプリケーションはデーモン/ヘルパーに要求を書き込み、データを含む応答を待ちます。

概説すると、GUI に次のコードが含まれます。

  • LaunchDaemon(): これは配管 (パイプまたはソケット)、フォークを作成し、子はデーモン プロセスを起動する前にファイル記述子を整理します (不要なものを閉じます)。
  • RequestDaemon(): デーモン/ヘルパーへのリクエストをパッケージ化し、情報をデーモンに書き込み、レスポンスを読み戻します。
  • TerminateDaemon(): デーモン/ヘルパーへの接続を閉じます。やるべき仕事がなくなったことを知り、終了します。

一方、デーモン/ヘルパー プログラムは次のことを行います。

  • 次の快適なループに落ち着きます。
    • 標準入力からリクエストを読み取ります
    • 有効性をチェックします
    • リクエストを実行します
    • 応答をフォーマットします (エラー、または正常)
    • それをメインGUIに書き戻します
    • 繰り返す
  • 入力から EOF を取得すると終了します。
  • 可能であれば、一度デバイスを開き、ルート権限を削除します。
    • これにより、攻撃への露出が最小限に抑えられます。
    • プログラムが root として実行されなくなった場合、root だけが実行できることを悪用することはできません。
    • ファイルが開かれると、権限は再度チェックされません (そのため、ルートとして実行されているデーモンはファイルを開き、ファイルを再度開かない場合はそのルート権限を破棄できます)。

周辺機器のアクセス許可が正しいかどうか、またはルートのみが読み取れるはずのデータを読み取る必要がある理由を確認する必要があります。

于 2011-01-16T15:08:10.340 に答える