UNIXドメインソケットはユーザーIDでロックできますか？
フォルダ/tmp/meを権限700で作成し、meでプロセスを開始した場合、/tmp/me/socketでリッスンソケットが開始されます。
- 私は現在、そのソケットへの接続はまったく同じサーバーで実行されているプロセス（悪意があるかどうかにかかわらず）から発生し、別のサーバーからの接続ではなかった（プロセスの1つを経由しない限り）と想定しています。
- そのソケットにアクセスできる唯一のユーザーが
meとrootであると仮定することもできますか？
特にSolarisについて伺います。
注：socketファイル自体に権限を設定しても、さまざまなオペレーティングシステムでは効果がないことを認識しています。そのため、socketファイルをディレクトリmeに含めることにしました。
私は現在、そのソケットへの接続がまったく同じサーバーで実行されているプロセスから発生したと想定しています
正しい。ファイルシステムソケットは、ファイルにアクセスできるプロセスによって読み取られる必要があります。
そのソケットにアクセスできる唯一のユーザーが私とrootであると仮定することもできますか？
はい。 meは権限を持つ唯一のユーザーであるため、そのフォルダーに入ってソケットを表示できるのはこれらのユーザーだけです。 rootはもちろんrootです。
はい、できますこれを行うことができますが、一部のシステムでは HP-などのUX 、ソケットファイルの権限は無視されます。親ディレクトリの権限は引き続き適用されますが、これらはソケットファイル自体の権限よりも管理が難しい場合があります。
Unixドメインソケットは、リモートプロセスのIDを検証する別の手段を提供します：_SCM_CREDENTIALS_、 unix(7) に記載されています。 root *のみが偽造された資格情報を渡すことができるため、これは絶対に簡単です。残念ながら、これは、ソケットファイルにファイルシステムのアクセス許可を設定することよりも標準的ではないようです。
_
SCM_CREDENTIALS_および抽象名前空間はLinux 2.2で導入されたものであり、移植可能なプログラムでは使用しないでください。 （一部のBSD派生システムも資格情報の受け渡しをサポートしていますが、実装の詳細は異なります。）
* Linuxでは、技術的には、外部プロセスは_CAP_SETUID_ 機能 を持っているだけで十分ですが、これは、漠然と合理的なシステム構成の下でのルートと同等の機能です（その他）言葉、攻撃者がその能力を持っている場合、彼らは実質的にルートを持っています）。外部プロセスは、 実際の、有効な、保存されたユーザー/グループID のいずれかを提供することも許可されていますが、これも脆弱性ではありません for同様の理由 （TL; DR：どのプロセスでも、必要に応じてこれらの資格情報を入れ替えることができます）。