Azure NetApp Files の NFSv4.x アクセス制御リストについて理解する

[アーティクル]
11/19/2023

NFSv4.x プロトコルは、アクセス制御リスト (ACL) の形式でアクセス制御を提供できます。これは概念的には、Windows NTFS アクセス許可を介して SMB で使用される ACL と似ています。 NFSv4.x ACL は、個々のアクセス制御エントリ (ACE)で構成され、それぞれがサーバーにアクセス制御ディレクティブを提供します。

各 NFSv4.x ACL は type:flags:principal:permissions の形式で作成されます。

型 – 定義されている ACL の型。有効な選択肢には、アクセス (A)、拒否 (D)、監査 (U)、アラーム (L) などがあります。 Azure NetApp Files では、アクセス、拒否、監査の ACL の型がサポートされています。ただし、ACL の監査は設定できますが、現在は監査ログは生成されません。
フラグ – ACL の追加コンテキストを追加します。 ACE フラグには、グループ、継承、および管理の 3 種類があります。フラグの詳細については、「NFSv4.x ACE フラグ」を参照してください。
プリンシパル – ACL が割り当てられているユーザーまたはグループを定義します。 NFSv4.x ACL のプリンシパルは、name@ID-DOMAIN-STRING.COM の形式を使用します。プリンシパルの詳細については、「NFSv4.x ユーザープリンシパルとグループプリンシパル」に関する記事を参照してください。
アクセス許可 – プリンシパルのアクセスレベルが定義されている場所。各アクセス許可には 1 文字が指定されます (たとえば、読み取りは "r" を、書き込みは "w" が指定されます)。フルアクセスには、使用可能な各アクセス許可文字が組み込まれています。詳細については、「NFSv4.x のアクセス許可」を参照してください。

A:g:group1@contoso.com:rwatTnNcCy は、type:flags:principal:permissions の形式に従った有効な ACL の例です。例の ACL は、contoso.com ID ドメイン内のグループ group1 へのフルアクセスを許可します。

NFSv4.x ACE フラグ

ACE フラグは、ACL の ACE に関する詳細情報を提供するのに役立ちます。たとえば、ACL にグループ ACE を追加する場合は、プリンシパルがユーザーではなくグループであることを指定するためにグループフラグを使用する必要があります。 Linux 環境では、ユーザーとグループ名が同じである可能性があるため、フラグによって ACE が確実に受け入れられるようにする必要があります。その後、NFS サーバーは定義されているプリンシパルの種類を認識する必要があります。

継承フラグや管理フラグなど、ACE を制御するために他のフラグも使用できます。

アクセスフラグと拒否フラグ

アクセス (A) フラグと拒否 (D) フラグは、セキュリティ ACE の種類を制御するために使用されます。アクセス ACE は、プリンシパルのファイルまたはフォルダーに対するアクセス許可のレベルを制御します。拒否 ACE は、プリンシパルがオブジェクトにアクセスできるようにするアクセス ACE が設定されている場合でも、プリンシパルがファイルまたはフォルダーにアクセスすることを明示的に禁止します。拒否 ACE は常にアクセス ACE より優先されます。一般論として、NFSv4.x ACL は "既定で拒否" モデルに従い、ACL が追加されていない場合は拒否が暗黙的であるため、拒否 ACE の使用は避けてください。拒否 ACE により、ACL 管理に不要な複雑な問題が発生する可能性があります。

継承フラグ

継承フラグは、継承フラグが設定された親ディレクトリの下に作成されたファイルに対する ACL の動作を制御します。継承フラグが設定されている場合、ファイルやディレクトリは親フォルダーから ACL を継承します。継承フラグはディレクトリにのみ適用できるため、サブディレクトリが作成されるとフラグが継承されます。継承フラグを持つ親ディレクトリの下に作成されたファイルは ACL を継承しますが、継承フラグは継承しません。

次の表では、使用可能な継承フラグとその動作について説明します。

継承フラグ	Behavior
d	- 親ディレクトリの下のディレクトリは ACL を継承します - 継承フラグも継承されます
f	- 親ディレクトリの下のファイルは ACL を継承します - ファイルは継承フラグを設定しません
i	継承のみ; ACL は現在のディレクトリには適用されませんが、ディレクトリの下のオブジェクトに継承を適用する必要があります
n	- 継承の反映なし ACL が継承されると、親の下のオブジェクトで継承フラグがクリアされます

NFSv4.x ACL の例

次の例では、個別の継承フラグを持つ 3 つの異なる ACE があります:

ディレクトリ継承のみ (di)
ファイル継承のみ (fi)
ファイル継承とディレクトリ継承の両方 (fdi)

# nfs4_getfacl acl-dir

# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

User1 には、ディレクトリのみを継承する ACL があります。親の下に作成されたサブディレクトリでは、ACL は継承されますが、親の下のファイルでは継承されません。

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file 
                       << ACL missing
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User2 には、ファイルえ継承フラグとディレクトリ継承フラグがあります。その結果、ACE エントリを持つディレクトリの下にあるファイルとディレクトリの両方が ACL を継承しますが、ファイルはフラグを継承しません。

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User3 には、ファイル継承フラグのみが含まれます。その結果、その ACE エントリを持つディレクトリの下にあるファイルのみが ACL を継承しますが、ディレクトリ ACE にのみ適用できるため、フラグは継承されません。

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

ACL で "no-propogate" (n) フラグが設定されている場合、親の下の後続のディレクトリ作成でフラグがクリアされます。次の例では、user2 には n フラグが設定されています。その結果、サブディレクトリはそのプリンシパルの継承フラグをクリアし、そのサブディレクトリの下に作成されたオブジェクトは user2 の ACE を継承しません。

#  nfs4_getfacl /mnt/acl-dir

# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

#  nfs4_getfacl inherit-dir/

# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# mkdir subdir
# nfs4_getfacl subdir

# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

継承フラグは NFSv4.x ACL をより簡単に管理する方法です。必要なたびに ACL を明示的に設定する必要がなくなります。

管理フラグ

NFSv4.x ACL の管理フラグは、監査 ACL とアラーム ACL でのみ使用される特殊なフラグです。これらのフラグは、アクションを実行するための成功 (S) または失敗 (F) アクセス試行を定義します。

Azure NetApp Files では、監査 ACE の管理フラグの設定がサポートされていますが、ACE は機能しません。さらに、Azure NetApp Files ではアラーム ACE はサポートされていません。

NFSv4.x ユーザープリンシパルとグループプリンシパル

NFSv4.x ACL では、ユーザープリンシパルとグループプリンシパルによって、ACE を適用する必要がある特定のオブジェクトが定義されます。プリンシパルは通常、name@ID-DOMAIN-STRING.COM 形式に従います。プリンシパルの "名前" 部分はユーザーまたはグループにすることができますが、NFSv4.x ID ドメインを指定する場合、そのユーザーまたはグループは LDAP サーバー接続を介して Azure NetApp Files で解決できる必要があります。 name@domainが Azure NetApp Files で解決できない場合、ACL 操作は "無効な引数" エラーで失敗します。

# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

LDAP グループ ID リストを使用して名前を解決できるかどうかを Azure NetApp Files 内で確認できます。 [サポートとトラブルシューティング]、[LDAP グループ ID の一覧] の順に移動します。

NFSv4.x ACL を使用したローカルユーザーおよびグループアクセス

ACL に数値 ID が指定されている場合に限って、NFSv4.x ACL でローカルユーザーとグループを使用することもできます。ドメイン ID が指定されたユーザー名または数値 ID は失敗します。

次に例を示します。

# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy

# nfs4_setfacl -a A:fdg:3003@CONTOSO.COM:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

ローカルユーザーまたはグループ ACL が設定されると、ACL の数値 ID に対応するすべてのユーザーまたはグループがオブジェクトへのアクセスを受け取ります。ローカルグループ ACL の場合、ユーザーはそのグループメンバーシップを Azure NetApp Files に渡します。ユーザーの要求を介してファイルにアクセスできるグループの数値 ID が Azure NetApp Files NFS サーバーに表示される場合、アクセスは ACL に従って許可されます。

クライアントからサーバーに渡される資格情報は、次に示すようにパケットキャプチャを介して確認できます。

注意事項:

ACL にローカルユーザーとグループを使用すると、ファイル/フォルダーにアクセスするすべてのクライアントに一致するユーザー ID とグループ ID が必要になります。
ACL に数値 ID を使用する場合、Azure NetApp Files は、受信要求が有効であること、およびアクセスを要求しているユーザーが、本人であり、実際にメンバーであると主張するグループのメンバーであることを暗黙的に信頼します。不適切なアクターが数値 ID を認識し、ユーザーとグループをローカルで作成する機能を持つクライアントを使用してネットワークにアクセスできる場合、ユーザーまたはグループの数値がスプーフィングされる可能性があります。
ユーザーが 16 を超えるグループのメンバーである場合、LDAP および拡張グループのサポートが使用されていない限り、16 番目のグループの後のグループ (英数字順) はファイルまたはフォルダーへのアクセスを拒否されます。
管理性とセキュリティを向上させるために NFSv4.x ACL を使用する場合は、LDAP と完全な name@domain 名の文字列を強くお勧めします。一元的に管理されたユーザーとグループのリポジトリは、保守が容易になり、スプーフィングが困難になり、不要なユーザーアクセスの可能性が低くなります。

NFSv4.x ID ドメイン

ID ドメインはプリンシパルの重要なコンポーネントであり、ID ドメインはクライアントと Azure NetApp Files 内の両方でユーザー名とグループ名 (具体的にはルート) と一致して、ファイル/フォルダーの所有権に正しく表示される必要があります。

Azure NetApp Files では、NFSv4.x ID ドメインがボリュームの DNS ドメイン設定に既定で設定されます。 NFS クライアントも、NFSv4.x ID ドメインの DNS ドメインに既定で設定されます。クライアントの DNS ドメインが Azure NetApp Files DNS ドメインと異なる場合は、不一致が発生します。 ls コマンドなどをを使用してファイルのアクセス許可を一覧表示すると、ユーザー/グループは "nobody" と表示されます。

NFS クライアントと Azure NetApp Files の間でドメインの不一致が発生した場合は、次のようなエラーがクライアントログで確認できます:

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'

NFS クライアントの ID ドメインは、/etc/idmapd.conf ファイルの "Domain" 設定を使用してオーバーライドできます。 (例: Domain = CONTOSO.COM)。

Azure NetApp Files では、NFSv4.1 ID ドメインを変更することもできます。詳細については、「方法: Azure NetApp Files の NFSv4.1 ID ドメイン構成」を参照してください。

NFSv4.x のアクセス許可

NFSv4.x のアクセス許可は、特定のユーザーまたはグループプリンシパルがファイルまたはフォルダーに対して持つアクセスレベルを制御する方法です。 NFSv3 のアクセス許可では、読み取り/書き込み/実行 (rwx) レベルのアクセス定義のみが許可されますが、NFSv4.x では、NFSv3 モードビットよりも改善された他のきめ細かいアクセス制御が提供されます。

ユーザーに対して設定できるアクセス許可は 13 個、グループに対して設定できるアクセス許可は 14 個あります。

アクセス許可レター	アクセス許可付与済み
r	データの読み取り/ファイルとフォルダーの一覧表示
w	データの書き込み/ファイルとフォルダーの作成
a	データの追加/サブディレクトリの作成
x	ファイルの実行/ディレクトリの走査
d	ファイル/ディレクトリを削除する
D	サブディレクトリを削除する (ディレクトリのみ)
t	属性の読み取り (GETATTR)
T	属性の書き込み (SETATTR/chmod)
n	名前付き属性の読み取り
N	名前付き属性を書き込む
c	ACL の読み取り
C	ACL の書き込み
o	書き込み所有者 (chown)
y	同期 I/O

アクセス許可が設定されている場合、ユーザーまたはグループプリンシパルは、割り当てられた権限に従います。

NFSv4.x アクセス許可の例

次の例は、さまざまな構成シナリオでさまざまなアクセス許可がどのように機能するかを示しています。

読み取りアクセス権を持つユーザー (r のみ)

読み取り専用アクセスでは、ユーザーは属性とデータを読み取ることができますが、書き込みアクセス (データ、属性、所有者) は拒否されます。

A::user1@CONTOSO.COM:r

sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root    0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text

読み取りアクセス (r) 属性と書き込み属性 (T) を持つユーザー

この例では、書き込み属性 (T) アクセス許可によりファイルに対するアクセス許可を変更できますが、読み取りアクセスのみが許可されるため、ファイルを作成することはできません。この構成は、NFSv4.x ACL が提供できるきめ細かいコントロールの種類を示しています。

A::user1@CONTOSO.COM:rT

sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:23 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
-rw-r--r--  1 root     root      10 Jul 12 16:22 file
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rw-r--r--  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:41 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied

モードビットを NFSv4.x ACL アクセス許可に変換する

CHmod が NFSv4.x ACL が割り当てられたオブジェクトを実行すると、一連のシステム ACL が新しいアクセス許可で更新されます。たとえば、アクセス許可が 755 に設定されている場合、システム ACL ファイルが更新されます。次の表は、モードビットの各数値が NFSv4 ACL アクセス許可で変換される内容を示しています。

すべてのアクセス許可の概要については、「NFSv4.x のアクセス許可」に関する表を参照してください。

モードビット数値	対応する NFSv4.x アクセス許可
1 – 実行 (X)	実行、属性の読み取り、ACL の読み取り、I/O の同期 (xtcy)
2 – 書き込み (W)	データの書き込み、追加、属性の読み取り、属性の書き込み、名前付き属性の書き込み、ACL の読み取り、I/O の同期 (watTNcy)
3 – 書き込み/実行 (wx)	データの書き込み、追加、実行、属性の読み取り、属性の書き込み、名前付き属性の書き込み、ACL の読み取り、I/O の同期 (waxtTNcy)
4 – 読み取り (R)	読み取り、属性の読み取り、名前付き属性の読み取り、ACL の読み取り、同期 I/O (rtncy)
5 – 読み取り/実行 (rx)	読み取り、実行、属性の読み取り、名前付き属性の読み取り、ACL の読み取り、同期 I/O (rxtncy)
6 – read/write (rw)	読み取り、書き込み、データの追加、属性の読み取り、属性の書き込み、名前付き属性の読み取り、名前付き属性の書き込み、ACL の読み取り、I/O の同期 (rwatTnNcy)
7 – 読み取り/書き込み/実行 (rwx)	フルコントロール/すべてのアクセス許可

NFSv4.x ACL と Azure NetApp Files の連携方法

Azure NetApp Files では、ボリュームで NFSv4.1 にアクセスが有効になっている場合、NFSv4.x ACL がネイティブでサポートされます。 ACL をサポートするためにボリュームで有効にするものはありませんが、NFSv4.1 ACL が最適に機能するためには、Azure NetApp Files が ACL に設定されているプリンシパルを安全に解決できるようにするために、UNIX ユーザーとグループを含む LDAP サーバーが必要です。ローカルユーザーは NFSv4.x ACL で使用できますが、LDAP サーバーで使用される ACL と同じレベルのセキュリティは提供されません。

Azure NetApp Files の ACL 機能に留意すべき事項があります。

ACL の継承

Azure NetApp Files では、ACL 継承フラグを使用して、NFSv4.x ACL の ACL 管理を簡略化できます。継承フラグが設定されている場合、親ディレクトリの ACL は、それ以上の操作を行わずにサブディレクトリとファイルに反映されます。 Azure NetApp Files は、RFC-7530 に従って標準 ACL 継承動作を実装します。

ACE を拒否する

Azure NetApp Files の拒否 ACE は、ユーザーまたはグループがファイルまたはフォルダーにアクセスできないように明示的に制限するために使用されます。アクセス許可のサブセットを定義して、拒否 ACE をきめ細かく制御できます。これらは RFC-7530 に記載されている標準的な方法で動作します。

ACL の保持

Azure NetApp Files のファイルまたはフォルダーに対して chmod を実行すると、システム ACE (OWNER@、GROUP@、EVERYONE@) 以外のすべての既存の ACE が ACL に保持されます。これらの ACE 権限は、chmod コマンドによって定義された数値モードビットによって定義されているように変更されます。 nfs4_setfacl コマンドを使用して手動で変更または削除された ACE のみを変更できます。

デュアルプロトコル環境での NFSv4.x ACL 動作

デュアルプロトコルとは、同じ Azure NetApp Files ボリュームで SMB と NFS の両方を使用することを指します。デュアルプロトコルアクセス制御は、ボリュームで使用されているセキュリティスタイルによって決まりますが、ユーザー名マッピングにより、互いに正常にマップされた Windows ユーザーと UNIX ユーザーがデータに対して同じアクセス許可を持つことが保証されます。

UNIX セキュリティスタイルのボリュームで NFSv4.x ACL が使用されている場合、デュアルプロトコルボリュームを使用し、SMB クライアントからデータにアクセスするときに、次の動作が観察されます。

Windows ユーザー名は、適切なアクセス制御の解決のために UNIX ユーザー名に適切にマップする必要があります。
(NFSv4.x ACL が適用される) UNIX セキュリティー・スタイル・ボリュームでは、Windows ユーザーのマップ先の LDAP サーバーに有効な UNIX ユーザーが存在しない場合は、マッピングに pcuser という既定の UNIX ユーザー (uid 数値 65534) が使用されます。
有効な UNIX ユーザーマッピングがない Windows ユーザーで書き込まれたファイルは、数値 ID 65534 によって所有されているように表示されます。これは、NFS マウントからの Linux クライアントの "nfsnobody" または "non" ユーザー名に対応します。これは、NFSv4.x ID ドメインの問題で通常見られる数値 ID 99 とは異なります。使用中の数値 ID を確認するには、ls -lan コマンドを使用します。
所有者が正しくないファイルは、UNIX モードビットまたは NFSv4.x ACL から予期される結果を提供しません。
NFSv4.x ACL は NFS クライアントから管理されます。 SMB クライアントは NFSv4.x ACL を表示または管理できません。

NFSv4.x ACL での Umask の影響

NFSv4 ACL は、ACL 継承を提供する機能を提供します。 ACL 継承とは、NFSv4 ACL が設定されたオブジェクトの下に作成されたファイルまたはフォルダーが、ACL 継承フラグの構成に基づいて ACL を継承できることを意味します。

Umask は、ディレクトリ内にファイルとフォルダーを作成するアクセス許可レベルを制御するために使用されます。既定では、Azure NetApp Files では、umask で継承された ACL をオーバーライドできます。これは、RFC-7530 に従って想定される動作です。

詳細については、「umask」を参照してください。

NFSv4.x ACL での Chmod/chown 動作

Azure NetApp Files では、所有権の変更 (chown) コマンドと変更モードビット (chmod) コマンドを使用して、NFSv3 および NFSv4.x のファイルとディレクトリのアクセス許可を管理できます。

NFSv4.x ACL を使用する場合、ファイルとフォルダーに適用されるコントロールが細かいほど、chmod コマンドの必要性が軽減されます。 NFSv4.x ACL では所有権が割り当てられないので、Chown にはまだ使用価値があります。

NFSv4.x ACL が適用されているファイルとフォルダー上の Azure NetApp Files で chmod を実行すると、オブジェクトのモードビットが変更されます。さらに、システム ACE のセットは、それらのモードビットを反映するように変更されます。システム ACE が削除されると、モードビットがクリアされます。例と詳細な説明については、以下のシステム ACE のセクションを参照してください。

Azure NetApp Files で chown を実行すると、割り当てられた所有者を変更できます。 NFSv4.x ACL を使用する場合、ファイルの所有権はモードビットを使用する場合ほど重要ではありません。ACL を使用すると、基本的な所有者/グループ/全員の概念ではできないアクセス許可の制御を行えるためです。 Azure NetApp Files の Chown はルートとして (ルートとして、または sudo を使用して) のみ実行できます。これは、ルートが所有権の変更のみを許可するようにエクスポートコントロールが構成されているためです。これは Azure NetApp Files の既定のエクスポートポリシー規則によって制御されるため、所有権の変更を許可する NFSv4.x ACL エントリは適用されません。

# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r--  1 user1    root     0 Jul 12 16:23 testdir

ボリュームのエクスポートポリシー規則を変更して、この動作を変更できます。ボリュームの [ポリシーのエクスポート] メニューで、[Chown モード]を "無制限" に変更します。

一度変更すると、root 以外のユーザーが適切なアクセス権を持っている場合は、所有権を変更できます。これには、"所有権の取得" NFSv4.x ACL アクセス許可 (文字 "o" で指定) が必要です。所有権を変更するユーザーが現在ファイルまたはフォルダーを所有している場合は、所有権を変更することもできます。

A::user1@contoso.com:rwatTnNcCy  << no ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied

A::user1@contoso.com:rwatTnNcCoy  << with ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root  root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root  root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294    0 Jul 14 16:31 newfile3

システム ACE

すべての ACL には、一連のシステム ACE (OWNER@、GROUP@、EVERYONE@) があります。次に例を示します。

A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

これらの ACE は、NFSv3 で表示されるクラシックモードビットのアクセス許可に対応し、それらのアクセス許可に直接関連付けられます。 chmod がオブジェクトで実行されると、これらのシステム ACL はそれらのアクセス許可を反映するように変更されます。

# nfs4_getfacl user1-file

# file: user1-file
A::user1@CONTOSO.COM:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

# chmod 755 user1-file

# nfs4_getfacl user1-file

# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy

これらのシステム ACE が削除されると、通常モードビット (rwx) がダッシュとして表示されるようにアクセス許可ビューが変更されます。

# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
----------  1 user1 group1     0 Jul 12 16:23 user1-file

ACL 上のユーザーおよびグループプリンシパル (およびルート) のみがオブジェクトにアクセスできるため、システム ACE の削除は、ファイルとフォルダーをさらにセキュリティで保護する方法です。システム ACE を削除すると、機能するためにモードビットビューに依存するアプリケーションが中断される可能性があります。

NFSv4.x ACL でのルートユーザーの動作

NFSv4.x ACL を使用したルートアクセスは、ルートがスカッシュされない限り制限できません。ルートスカッシュは、ルートが匿名ユーザーにマップされ、アクセスを制限するエクスポートポリシー規則が構成されている場所です。ボリュームの [エクスポートポリシー] メニューから[ルートアクセス] のポリシー規則をオフに変更することで、ルートアクセスを構成できます。

ルートスカッシュを構成するには、ボリュームの [エクスポートポリシー] メニューに移動し、ポリシー規則の “ルートアクセス” を “オフ” に変更します。

匿名ユーザー nfsnobody:65534 に対するルートアクセスルートスカッシュを無効にした場合の影響。ルートアクセスでは、所有権を変更できません。

root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2  root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root   root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1  root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root   root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2  1002          0 4096 Jul 14 16:31 .
drwxrwxrwx 5     0          0 4096 Jul 13 13:46 ..
-rw-r--r-- 1  1001          0    0 Jul 14 15:45 newfile
-rw-r--r-- 1     0          0    0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted

または、デュアルプロトコル環境では、NTFS ACL を使用してルートアクセスを細かく制限できます。

次の方法で共有

Azure NetApp Files の NFSv4.x アクセス制御リストについて理解する

NFSv4.x ACE フラグ

アクセスフラグと拒否フラグ

継承フラグ

NFSv4.x ACL の例

管理フラグ

NFSv4.x ユーザープリンシパルとグループプリンシパル

NFSv4.x ACL を使用したローカルユーザーおよびグループアクセス

NFSv4.x ID ドメイン

NFSv4.x のアクセス許可

NFSv4.x アクセス許可の例

モードビットを NFSv4.x ACL アクセス許可に変換する

NFSv4.x ACL と Azure NetApp Files の連携方法

ACL の継承

ACE を拒否する

ACL の保持

デュアルプロトコル環境での NFSv4.x ACL 動作

NFSv4.x ACL での Umask の影響

NFSv4.x ACL での Chmod/chown 動作

システム ACE

NFSv4.x ACL でのルートユーザーの動作

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure NetApp Files の NFSv4.x アクセス制御リストについて理解する

NFSv4.x ACE フラグ

アクセス フラグと拒否フラグ

継承フラグ

NFSv4.x ACL の例

管理フラグ

NFSv4.x ユーザー プリンシパルとグループ プリンシパル

NFSv4.x ACL を使用したローカル ユーザーおよびグループ アクセス

NFSv4.x ID ドメイン

NFSv4.x のアクセス許可

NFSv4.x アクセス許可の例

モード ビットを NFSv4.x ACL アクセス許可に変換する

NFSv4.x ACL と Azure NetApp Files の連携方法

ACL の継承

ACE を拒否する

ACL の保持

デュアルプロトコル環境での NFSv4.x ACL 動作

NFSv4.x ACL での Umask の影響

NFSv4.x ACL での Chmod/chown 動作

システム ACE

NFSv4.x ACL でのルート ユーザーの動作

次のステップ

フィードバック

その他のリソース

アクセスフラグと拒否フラグ

NFSv4.x ユーザープリンシパルとグループプリンシパル

NFSv4.x ACL を使用したローカルユーザーおよびグループアクセス

モードビットを NFSv4.x ACL アクセス許可に変換する

NFSv4.x ACL でのルートユーザーの動作