問題タブ [posix]

現在のプロセスに割り当てられた最大のファイル記述子番号を取得する移植可能な方法 (POSIX) はありますか?

たとえば、AIXで番号を取得する良い方法があることは知っていますが、移植可能な方法を探しています。

私が尋ねている理由は、開いているすべてのファイル記述子を閉じたいからです。私のプログラムは、ルートとして実行され、ルート以外のユーザーの子プログラムをフォークおよび実行するサーバーです。子プロセスで特権ファイル記述子を開いたままにしておくと、セキュリティ上の問題があります。一部のファイル記述子は、私が制御できないコード (C ライブラリ、サードパーティ ライブラリなど) によって開かれている可能性があるため、どちらにも依存できませんFD_CLOEXEC。

その情報をピアツーピア ネットワークに公開するために、自分の IP アドレスを取得しようとしています。POSIX/C ではがありますが、これは常にorgetaddrinfo(NULL, ...)を返すようで、私には役に立ちません。INADDR_ANYINADDR_LOOPBACK

助言がありますか？

マスター スレッドといくつかのワーカー スレッドを使用してプログラムを作成しており、シグナル処理を正しく行いたいと考えています。私の問題は次のとおりです。

マスタースレッドが開始し、すべての割り当てを行います

マスター スレッドが SIGINT シグナル ハンドラを設定する

マスター スレッドはワーカー スレッドを開始します。ワーカー スレッドは特別なクリーンアップを必要としませんが、システム コールまたはセマフォでスリープ状態になる可能性があります。

SIGINT が受信されると、それを受信するスレッドは 1 つだけであると理解しています。そのため、スレッドがシステム コールまたはセマフォでスリープしている場合、それらは起動されず、ワーカー スレッドに pthread_join できず、マスター スレッドで必要なすべてのクリーンアップを実行できません。

次のシグナル ハンドラーで問題を解決できますか?

私が期待しているのは、SIGINT を受信すると、すべてのスレッドが別のシグナルで通知され、ブロッキング呼び出しから抜け出し、g_do_cleanupフラグを確認して正常に終了することです。

これを適切に行う方法についてのコメントやリンクは大歓迎です。

編集:特定の条件で待機している複数のスレッドをウェイクアップする方法を探しているわけではないので、 pthread_cond_signal アプローチが探しているものではないと思います。私が欲しいのは：

• ブロッキング呼び出しでブロックされたすべてのスレッドがこれらの呼び出しから戻る方法を見つけます。
• または、メインのスレッドを除くすべてのスレッドを強制終了します。

サブプロセスを生成するデーモンプロセスがあります。これらのサブプロセスは、デーモンと通信する必要がある場合があります。これらのサブプロセスのみがデーモンとの通信を許可されていることを確認したいと思います。

これを次のように実装したいと思います。

• 起動時に、デーモンは/ dev/urandomを読み取ることによってランダムな128バイトのシークレットトークンを生成します。/ dev / randomは、リーダーを任意の時間ブロックする可能性があるため、適切ではありません。
• デーモンはUnixドメインソケットでリッスンします。
• デーモンは、シークレットトークンとソケットのファイル名を環境変数に入れます。生成されるすべてのサブプロセスは、ファイル名とシークレットトークンを使用してデーモンに接続できます。
• シークレットトークンが正しくない限り、デーモンは接続を拒否します。

質問：

• / dev/randomのエントロピーは/dev/urandomよりも高いことを私は知っています。しかし、/ dev / urandomで十分ですか？そうでない場合は、何を使用すればよいですか？
• トークンのサイズは十分に大きいですか？
• トークンが保存されているメモリをロックする必要がありますか？デーモンは起動するたびに異なるトークンを生成するため、必要ではないと思います。したがって、攻撃者がハードドライブを盗み、スワップファイルからトークンを抽出するまでには、デーモンはすでに役に立たないはずです。
• シャットダウン中にトークンが保存されているメモリを無効にする必要がありますか？
• 他に私がすべきことはありますか？

また、さまざまな要件があるため、デーモンとサブプロセス間の通信を許可するために無名パイプを使用することはできません。

これは設計上の決定に関するものであり、別のサービスを採用する場合の長所と短所を理解しています。そのため、2 つの無関係なサーバーを持つ 2 つのサービスがあり、1 つはポート 10000 でリッスンし、もう 1 つは 3 つの異なるポートを介して 3 つの異なる要求に応答する xinetd サーバーです (そのクライアントは nc サーバーのポート 1|ポート 2|ポート 3 を使用してデータを取得します)。

ある日、セキュリティ上の問題により xinetd サーバーを停止する必要があり、最初のサーバーが同じデータを保持しているという理由だけで、最初のサーバーに USR1 シグナルを送信し、同じ公開データを公開することで xinetd サーバーを採用することにしました。したがって、最初のサーバーでシグナル処理を再定義するロジックを追加する必要があります。USR1 (10、16、および 30) を使用する予定です。たとえば、xinetd サーバーで kill -10 first_server を実行すると、最初のサーバーは古いサーバーが送信していたのと同じデータを吐き出し、それでも最初のポートにダンプします。 . Unix シグナルの使用法を悪用し、もちろん POXIS および Linux で事前定義された 10、16、および 30 シグナルの動作を再定義しているため、これは悪い設計であるという議論があります。これは本当に技術的に悪いのでしょうか？システムにどのような害を及ぼすでしょうか？

一度に許可される何かの同時実行数を制御するラッパーを Linux で作成しようとしています。そのために、システム全体のカウント セマフォを使用しています。セマフォを作成し、 を実行しsem_wait()、子プロセスを起動してから、子プロセスがsem_post()終了したときに実行します。それは結構です。

問題は、このラッパーに送信されたシグナルを安全に処理する方法です。シグナルをキャッチしない場合、コマンドは を実行せずに終了しsem_post()、セマフォ カウントが永続的に 1 つ減少する可能性があります。だから、私はシグナルハンドラーを作成しましたsem_post(). しかし、それでも問題があります。

が実行される前にハンドラーがアタッチされている場合、が完了sem_wait()する前にシグナルが到着し、がなくても が発生する可能性があります。シグナルハンドラを設定する前に行うと、逆のことが可能です。sem_wait()sem_post()sem_wait()sem_wait()

明らかな次のステップは、ハンドラーと のセットアップ中にシグナルをブロックすることでしたsem_wait()。これは私が今持っているものの擬似コードです:

現在の問題は、sem_wait()缶がブロックされ、その間、信号がブロックされることです。プロセスを強制終了しようとするユーザーは、最終的に「kill -9」に頼る可能性があります。これは、何があってもそのケースを処理できないため、推奨したくない動作です。sem_trywait()短時間使用してテストすることもできますsigpending()が、セマフォで最も長く待機しているプロセスが次に実行されるという保証がなくなるため、公平性に影響します。

セマフォの取得中にシグナルを処理できる本当に安全なソリューションはありますか? 「セマフォがありますか」グローバルに頼ってシグナルブロッキングを削除することを検討していますが、セマフォを取得してグローバルを設定することはアトミックではありませんが、待機中にシグナルをブロックするよりは良いかもしれないため、100％安全ではありません。

IPCのポートでTCP/IPサービスを実行したいとします。とにかく通信したいプロセスにポート番号を渡すので、ポート番号は重要ではありません。システムからまだ利用可能なランダムで高い（通常は> 49152）ポート番号を取得するための最良の方法は何ですか？POSIXに使用できるものはありますか？

FTPサーバーがこれを頻繁に必要とすることを私は知っています。

私は最近 Linux でメッセージ キュー (System V、しかし POSIX も問題ないはず) をいじっていますが、私のアプリケーションには完璧に思えますが、The Art of Unix Programming を読んだ後、それらが本当に良い選択であるかどうかはわかりません。 .

http://www.faqs.org/docs/artu/ch07s02.html#id2922148

System V IPC の上位のメッセージ パッシング レイヤーは、ほとんど使用されなくなりました。共有メモリとセマフォで構成される下位層には、相互排他ロックと、同じマシン上で実行されているプロセス間でのグローバル データ共有が必要な状況下でも重要なアプリケーションがあります。これらの System V 共有メモリ機能は POSIX 共有メモリ API に発展し、Linux、BSD、MacOS X、および Windows でサポートされましたが、従来の MacOS ではサポートされませんでした。

http://www.faqs.org/docs/artu/ch07s03.html#id2923376

System V IPC 機能は、Linux およびその他の最新の Unix に存在します。ただし、これらはレガシー機能であるため、頻繁に実行されることはありません。2003 年半ばの時点で、Linux バージョンにはまだバグがあることが知られています。それらを修正するのに十分なほど気にする人は誰もいないようです。

最近の Linux バージョンでも、System V メッセージ キューにはまだバグがありますか? 著者が POSIX メッセージ キューは問題ないと言っているのかどうかわかりません。

ソケットは、ほとんどすべて (?) で優先される IPC のようですが、ソケットなどを使用してメッセージ キューを実装するのが非常に簡単であることがわかりません。それとも私が複雑に考えすぎているのでしょうか？

組み込み Linux を使用していることが関連しているかどうかわかりません。