12

STREAM unix ドメイン ソケットのリッスン バックログがいっぱいにconnect(2)なると、ほとんどのシステムで ECONNREFUSED で失敗します。EAGAIN を返すことが望ましいでしょう。

その理由は、デッド ソケットの 2 つのケース (ファイル システムにノードが存在するが、リッスンしているプロセスがない) と完全なバックログのケースを区別できると非常に便利だからです。デッド ソケットをクリーンアップするコードを含む Linux ソフトウェアを移植するときにこの問題に遭遇しましたが、ソケットをスパミングしてバックログを埋めることでコードを騙してソケットを削除できる場合、セキュリティ上の脆弱性があります。

Linux のみが EAGAIN を返します。AIX、Solaris、および Darwin は BSD の動作に従います (それぞれでテスト済み)。

POSIX では、connect() (リンク)からの戻りコードとして EAGAIN がリストされていないため、ここでコンプライアンスの問題が発生する可能性があります。

全員を Linux に合わせて変更するための最善の方法は何ですか? 私は、Oracle、Apple、FreeBSD PR にバグ レポートを提出し、各組織のメーリング リストで争うことができました。それとも、標準化団体 (Austin グループ) の誰かをせがむ必要がありますか? 利点は明らかですが、ここで全員に着替えさせることをお勧めしますか?

4

2 に答える 2

0

ほとんどの場合と同様に、情報源に移動するよう説得できれば、すべてのユーザーが従う必要があります。したがって、POSIX で問題を修正することが最善の方法です。次に、すべての実装が準拠する必要があります。

別の解決策は、それが機能するシステムを使用することです。つまり、Linux マシンのみを使用します (この場合)。また、Linux では、カーネルを微調整して、何らかの方法で動作させることができます (これは BSD でも可能です)。

さて、この問題に関する私の意見では、ここでの主な問題は、意図したサービスではなくメッセージを受信するためにソケットを開こうとする不正なプロセスであるように思えます。私の質問は次のとおりです。それはどのくらいの頻度で起こりますか?

systemctl に似たシステムを使用する場合、サービスのインスタンスが 1 つだけ実行されます。AF_UNIXサービスのその時点でソケットを開こうとしている場合、実際にそうしようとしているのはあなただけです。したがって、ファイルを削除しても問題ありません。

システムで不正なソフトウェアの実行を許可している場合 (つまり、システムが公開されていて、アクセスできるユーザーが多数いる場合、人々がサーバーに telnet で接続していた昔のように)、代わりに TCP または UDP 接続を使用する必要があるかもしれません。

最後に、別のソフトウェアがそのAF_UNIXソケットを開くことができる場合、その不正なソフトウェアが (1) あなたのソケットを削除し、(2)bind()が新たに、(3)あなたの新しいクライアントは、あなたがまだ実行していて接続をリッスンしているにもかかわらず、あなたのサービスではなく、その不正なソフトウェアと話しているのです...隠しファイルソケットで。(古いクライアントは引き続きサービスと通信し、再接続するクライアントは不正なソフトウェアと通信することに注意してください)。

それで... あなたの問題はどこですか？

于 2021-07-21T17:04:34.933 に答える