人間の目には光受容体と呼ばれる光感受性細胞があり、光感受性細胞は桿体(かんたい)細胞と錐体(すいたい)細胞の2種類に分かれます。そのうち錐体細胞は明るい光の中で赤、緑、青を感知することで、3色を組み合わせて色覚を脳に解釈させています。
カリフォルニア大学バークレー校のコンピュータサイエンス博士課程の学生であるジェームズ・フォン氏らは、錐体細胞ごとに光をとどけることで人間の目の光受容体の活動を直接制御する「Oz(オズ)」という技術を発表しました。Ozという名前は、街の輝きが目をくらませないようにするためにかける緑色のメガネが登場する「オズの魔法使い」に由来しています。
研究では実際に、Ozによってオレンジから黄色、緑、青緑まで、さまざまな色相を正常に表示できることが確認されました。さらに、M錐体のみを刺激する試みによって、自然な人間の色域を超えた新しい色が表示されることが示されました。被験者は「これまでにない彩度の青緑色に見える」と報告しています。
研究者たちはこの色を「olo」と名付け、oloの理想的なバージョンを「純粋なM錐体活性化」と定義しています。oloというのは「0,1,0」という3D色の座標に由来しており、M錐体のみが活性化していることを示しています。
⇧ 気になるのは、
「色覚異常」は医学的に認められている学術用語であるが、不適切であるという批判も多く「色覚障害」「色弱」「小数色覚」などの用語も使われる。以前は長らく「色盲」と呼ばれていたが、現在は医学的にも廃止され使用されていない。また色覚異常に関連して「色覚特性」「色覚多様性」という用語も使われる
⇧「色」の見え方が特殊な人にも効果があるのかですかね。
NFS（Network File System）
「NFS（Network File System）」については、
Network File System(NFS)は主にUNIXで利用される分散ファイルシステムおよびそのプロトコルである。
概要
NFSは、ローカルに接続されたストレージをネットワークを介してリモートの計算機に提供する分散ファイルシステムとそのプロトコルである。マウントされたNFSボリュームは、ネットワーク上にあることを意識せずローカルと同じように利用出来る。
NFS v2, v3 では、Network File System#関連プロトコルで述べるように、ファイルロック機能やクォータ管理機能などはNFSプロトコル本体に含まれず、それぞれ別のプロトコルによって提供される。これらは NFS v4 ではプロトコル本体に含まれている。
⇧ とあるように、
の最低、2台のマシンは必要になってくると思われますが、
⇧ 上図がイメージし易いかと。
Azure Storageサービスでは、Azure FilesとAzure Blob StorageがNFSをサポートしている
で、前回、
⇧ 上記の記事の時に、「Azure Storage」サービスでは、
| No | Azure Storage サービス | NFCサポート | |
|---|---|---|---|
| 可否 | バージョン | ||
| 1 | Azure Blob Storage | ✅ | 3.0 |
| 2 | Azure Files | ✅ | 4.1 |
の2つが「NFS（Network File System）」をサポートしているっぽい。
Azure Filesは、NFS 4.1に対応とあるがアクセス制御はどうなっているのか
公式のドキュメントを確認してみるものの、
サポート
現時点では、NFS バージョン 4.1 のみがサポートされています。 NFS 4.1 共有のみが、FileStorage ストレージ アカウント タイプ内でサポートされています (Premium ファイル共有のみ)。
https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-how-to-mount-nfs-shares
NFS Azure ファイル共有では、4.1 プロトコル仕様のほとんどの機能がサポートされています。 あらゆる種類の委任とコールバック、Kerberos 認証、転送中の暗号化など、一部の機能はサポートされていません。
https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-how-to-mount-nfs-shares
Azure Files の承認とアクセス制御の概要
ストレージ アカウントでの ID ベースの認証 にどの ID ソースを選択するかに関係なく、承認とアクセス制御を構成する必要があります。 Azure Files では、共有レベルとディレクトリやファイル レベルの両方で、ユーザー アクセスに認可が適用されます。
https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-authorization-overview
⇧「Azure Files」の「NFS（Network File System）」の「アクセス制御」についての記載が無いのだが...
「トラブルシューティング」にしか記載が無いという残念過ぎる公式のドキュメント...
原因
NFS ファイル共有に対するアクセス許可は、Azure Files サービスではなく、クライアント OS によって適用されます。 NFS ファイル共有で Root Squash 設定が有効になっている場合、クライアント システムのルート ユーザーは、アクセス制御のために匿名 (特権のない) ユーザーとして扱われます。
つまり、クライアント システムで root としてログインしている場合でも、 chown コマンドを使用して、所有していないファイルとディレクトリの所有権を変更することはできません。
ソリューション
Azure portal でファイル共有に移動し、 Properties を選択します。 Root スカッシュ設定を ルート スカッシュに変更します。 詳細については、「 Azure Files のルート スカッシュの構成」を参照してください。
ルート スカッシュが有効になっていない、クライアント システムのルート ユーザーは、サーバー システムのルート ユーザーと同じ権限を持ちます。 chownを使用して、現在の所有者に関係なく、共有内の任意のファイルまたはディレクトリの所有権を変更できるようになりました。 変更を加えた後、必要に応じて Root スカッシュ を再度有効にすることができます。
⇧ とあるのだが、「クライアント システム」側の「所有者」と「Azure Portal」側で操作している「ユーザー」の関係が分からないんだが...
次の表は、特定のルート スカッシュ オプションが構成されている場合にサーバーから観察される UID の動作を示しています。
⇧ 分り辛い...
「Azure Portal」側で「ルート スカッシュ設定」なるものが有効になっている必要があるようなのだが、
| No | 設定 | サーバー システム | クライアント システム |
|---|---|---|---|
| Azure Files | Azure Virtual Machine | ||
| 1 | ルート スカッシュなし | ※1 | ※1 |
| 2 | すべてスカッシュ | 匿名ユーザー | すべての UID と GID |
| 3 | ルート スカッシュ | 匿名 UID/GID | UID/GID 0 (ルート) |
※1「サーバー システム」側から誰でも何でもできるということかと。要するにセキュリティは全く考慮されていない。
という感じらしい。
「ChatGPT」氏に質問したところ、以下のような回答が返ってきた。
⇧ とりあえず、「ChatGPT」氏の回答が「幻覚（ハルシネーション）」ではない、つまり正しいと仮定した場合、
- すべてスカッシュ
- ルート スカッシュ
のいずれかの選択肢になってくる気はするのだが、「書き込み」も許容するとなると、「ルート スカッシュ」一択になるってことですかね。
Azure FilesにNFSでマウントしているディレクトリに対するアクセス制御の切り替えをどうすべきか
話が脱線するのだが、相も変わらず、「Microsoft」のドキュメントが分かり辛いのだが、「Azure Files」で「NFS」を利用するには、
手順 3: NFS Azure ファイル共有をマウントする
共有は、Azure portal を使用してマウントできます。 /etc/fstab ファイルにレコードを作成して、Linux サーバーまたは VM が起動するたびに共有を自動的にマウントすることもできます。
⇧ とあり、
の2つの方法が用意されているということらしい。
逆に言うと、2つの方法が全量ということになると。
で、
⇧ とあり、
『設定 sec=sys では、AUTH_SYS を使用して NFS 操作を認証するローカル UNIX UID および GID が使用されます。』
とあるのだが、「ルート スカッシュ設定」との関係について言及されていないのがサッパリ謎なのだが...
何と言うか「Azure Files（NFS サーバー）」にログインしたユーザーの「UID」に対して、アクセス権を付与したりできるのかが分からない...
トラブルシューティングの方法だと、
ルート スカッシュが有効になっていない、クライアント システムのルート ユーザーは、サーバー システムのルート ユーザーと同じ権限を持ちます。 chownを使用して、現在の所有者に関係なく、共有内の任意のファイルまたはディレクトリの所有権を変更できるようになりました。 変更を加えた後、必要に応じて Root スカッシュ を再度有効にすることができます。
⇧ どのUIDのユーザーに対して、「chown」を実施するのかがハッキリしない...
⇧ 上記サイト様によりますと、「RHEL（RedHat Enterprise Linux）」系だと、「nobody」が利用されるらしい。
「Azure Files（NFS サーバー）」側で「アップロード」されたファイルは、「Azure Virtual Machine（NFS クライアント）」側では、「所有者」が「nobody」になるってことなんかね？
ただ、「Azure Files」が「Microsoft Azure」の「マネージドサービス」であるからして、利用している「Linuxディストリビューション」が不明なので、「nobody」になるのかどうかが分らんのよね...
後、「Azure Files」の公式のドキュメントで、
『 chownを使用して、現在の所有者に関係なく、共有内の任意のファイルまたはディレクトリの所有権を変更できるようになりました。』
とあるのだが、単純に「ファイル数」が膨大な場合に、パフォーマンス劣化する点についても言及されていないとか、公式のドキュメントが兎にも角にも酷いのよね...
とりあえず、「Azure Virtual Machine（NFS クライアント）」側では、「Azure」側のユーザーは、一律「UID:65534, GID:65534 の nobody ユーザ」という扱いになるということですかね。
ということは、「Azure Virtual Machine（NFS クライアント）」側で作成される「ディレクトリ」や「ファイル」があったとして、その「ディレクトリ」や「ファイル」の「グループ」に一時的に「nobody」ユーザーの「UID」に紐付く「Azure Virtual Machine（NFS クライアント）」側の「UID」を追加したりできるってことなんかね？
「Azure Files」の「NFS（Network File System）」何も分らん...
Azure Blob Storageも「ルート スカッシュ」の設定が必要
公式のドキュメントを見た感じでは、
⇧「Azure Blob Storage」の方も「NFS（Network File System）」を利用する場合は、「ルート スカッシュ」の設定が用意されているっぽい。
-
ストレージ アカウントで NFS 3.0 のサポートを一度有効にすると、無効に戻すことはできません。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/network-file-system-protocol-known-issues
⇧ サラッと、書いているところが恐ろしい...
まぁ、「ディレクトリ」や「ファイル」が作成されるのを検知して、作成されたタイミングで「アクセス権」を設定しておくのが良さそうということですかね。
毎度モヤモヤ感が半端ない…
今回はこのへんで。
