ホワイトアウトファイルをAUFS形式からカーネルオーバーレイFS形式に変換しようとしています。これ必要拡張属性 trust.overlay.opaque=y を使用して特定のディレクトリを表示します。残念ながら、FreeBSDは少なくとも基本的にユーザーとシステムの名前空間の拡張属性のみをサポートしているようです。この制限を回避する方法はありますか？これエクストラマニュアルつまり、マウント可能な一部のファイルシステムは、信頼できる名前空間を含む他の名前空間をサポートできますが、信頼できる名前空間の使用を許可するマウント可能なファイルシステムを見つけることができません。
残念ながら、サポートされているFreeBSDバージョンにアップグレードすることはできません。また、KOFSには信頼できる名前空間の代わりにユーザーの名前空間から不透明な白いファイルを読み取るフラグがありますが、まだtempfsの上にKOFSを構築しています。サポートしていないユーザーネームスペース拡張属性。
どんなアイデアがありますか？
答え1
重要な要約：特定のユースケースでは、システム名前空間を使用する必要があります。
FreeBSDのextattr（9）のマニュアルページはここで少し冗長に説明されていますが、実際には2つの標準属性の名前空間（userとsystem）が定義されていますが、ファイルシステムAPIは単に整数なので、技術的に異なる名前空間です。を許可するということです。 LinuxのAPIも同様にオープンしていますが、4つの標準ネームスペースが定義されています。ただし、他の名前空間は名前の文字列プレフィックスなので、技術的に受け入れられます。
どちらの場合も、実際に重要なのは、使用しているファイルシステムが実際にどの属性と意味をサポートしているかです。すでにご存じのように、FreeBSDのtmpfsはシステム属性のみをサポートします。
Linux"user"ネームスペースはFreeBSDユーザーネームスペース（EXTATTR_NAMESPACE_USERまたは1）に直接マップされます。許容されるものと許可されていないものにはわずかな微妙な違いがあるかもしれません。これは、ファイルモードビットに基づいてPOSIXセマンティクスに従うことを期待している人にとっては驚くかもしれませんが、権限のないユーザーは通常、自分のファイルユーザープロパティで作業することを期待できます。
Linuxの"security"、"system"および名前空間はFreeBSDのシステム名前空間（、または2）"trusted"にある程度マップされます。EXTATTR_NAMESPACE_SYSTEMここにアクセスするには高い権限が必要です。 Linuxでは特定の名前空間と属性名によって異なりますが、CAP_SYS_ADMINFreeBSDではこの機能が良い開始点になりますPRIV_VFS_EXTATTR_SYSTEM。
Linuxに1つではなく3つのシステム名前空間がある正確な理由は時間の経過とともに忘れられたかもしれませんが、カーネル開発者は名前の衝突を避けるためにさまざまなシステムコンポーネントにプレフィックスを提供したかったので、これは最もきれいなアプローチと見なされています。 （カーネル以外のシステム属性は、"trusted"当時はまだ重要ではないようです。）
完全性のために、MacOSには拡張属性もあります。 APIはLinuxと非常によく似ていますが、名前空間の面では少し混乱しています。属性には、たとえばプレフィックスがある傾向がありますが、"com.apple."これは名前の衝突を避けるための規則にすぎず、カーネルはそれにほとんど注意を払わないでしょう。通常、これらの名前は追加のオプションを指定しない限り、ユーザーの名前空間にあります。XATTR_SHOWCOMPRESSIONこの場合、別の名前が表示され、その一部はルートからもアクセスできません。その間、Solarisの言及は少ないほど良いです。