web-dev-qa-db-ja.com

ソケットパスの長さが100文字に制限されているのはなぜですか?

Unixシステムでは、通常、パス名には実質的に長さの制限はありません(Linuxでは4096文字)... 約100文字Linuxでは107文字)に制限されているソケットファイルパスを除く )。

  • 最初の質問:なぜこのような低い制限なのか?

現在の作業ディレクトリを変更し、さまざまなディレクトリにいくつかのソケットファイルをすべて同じパスを使用して作成することで、この制限を回避できる可能性があることを確認しました./myfile.socklsofが同じソケットファイルパスでリッスンしているすべてを表示しているにもかかわらず、クライアントアプリケーションは予期されたサーバープロセスに正しく接続しているようです。

  • この回避策は信頼できますか、それとも幸運でしたか?
  • この動作はLinuxに固有のものですか、この回避策は他のUnixにも適用できますか?
20
WhiteWinterWolf

他のプラットフォームとの互換性、またはsnprintf()strncpy()の使用中のオーバーランを回避するための古いものとの互換性。

Michael Kerriskが 彼の本1165ページ で説明しています-第57章、ソケット:Unixドメイン:

SUSv3は、Sun_pathフィールドのサイズを指定しません。初期のBSD実装では108バイトと104バイトを使用し、現在の1つの実装(HP-UX 11)では92バイトを使用しています。移植可能なアプリケーションは、この低い値にコード化し、このフィールドに書き込むときにバッファーのオーバーランを回避するためにsnprintf()またはstrncpy()を使用する必要があります。

一部のソケットは110文字の長さだったので、Dockerの人たちはそれをからかいさえしました。

これが、LINUXが108文字のソケットを使用する理由です。これは変更できますか?もちろん。そしてこれが、最初にこの制限が古いオペレーティングシステムで作成された理由です。

答えを引用する:

それは、便利なカーネルデータ構造で利用可能なスペースと一致させることでした。

McKusickらによる「4.4BSDオペレーティングシステムの設計と実装」の引用al。 (369ページ):

メモリ管理機能は、mbufと​​呼ばれるデータ構造を中心に展開します。 Mbuf(メモリバッファー)は128バイトの長さで、この領域の100または108バイトはデータストレージ用に予約されています。

その他のOS(UNIXドメインソケット):

21
user34720

その理由について、nwildnerはすでに 優れた答え を書いています。

ここでは、方法と相対パスの使用に焦点を当てます。

内部的には、ソケットファイルは名前で検索することもできますが(おそらく)、iノードで検索します。 Linuxでは、このルックアップはnet/unix/af_unix.cで定義された関数unix_find_socket_byinode()によって保証されます。

これは次のように簡単に確認できます。

  • 2つのディレクトリA /B /を作成します。
  • 各ディレクトリの下で、プロセスに同じ名前のソケットファイルをリッスンさせます。 socat では、次のようなコマンドを使用します。
$ socat UNIX-LISTEN:./my.sock -
  • ここで、A/my.sockB /に、またはその逆に移動して、ソケットファイルを交換します。
  • 今後、クライアントアプリケーションがA/my.sockに接続すると、サーバーに接続します[〜#〜] b [〜#〜]、そしてB/my.sockに接続すると、サーバーに接続します[〜#〜] a [〜#〜] (ただし、通信が終了すると、サーバープロセスは自身のソケットファイルと思われるものを正当に削除する場合があります)。

私はこの動作を少数のUnixシステム(Linux Debian、FreeBSD、およびOpenIndianaで多様性を得るために)で確認したので、この動作は、標準的ではないにしても、少なくとも広範囲にわたるようです。

絶対パスは通常、クライアントプロセスがサーバーとの初期通信を確立する方法を知らない可能性があるため、クライアントプロセスとサーバープロセス間の規則として使用されます。

ただし、この最初の通信が問題にならない場合は、ソケットファイルの作成に相対パスを使用しても安全であると思われ、ソケットファイルの場所がサーバープロセスによって直接制御されていない場合のパス長の問題を回避できます。

6
WhiteWinterWolf