このトピックでは、NFSv4 アクセス制御リスト (ACL) および POSIX ACL の機能について説明します。
Apsara File Storage NAS NFSv4 ACL の機能
- タイプが allow のアクセス制御エントリ (ACE) のみサポートされています。 deny、audit、および alarm の ACE はサポートされていません。
タイプが deny の ACE を使用すると、アクセス権限の設定が複雑になります。 ほとんどの場合、複雑な設定はエンドユーザーの混乱を招き、潜在的なセキュリティリスクを増大させます。 業界の共通認識に従って、タイプが deny の ACE は使用しないことを推奨いたします。 タイプが deny の ACE が推奨されない理由の詳細については、「 よくある質問」 をご参照ください。
タイプが audit および alarm の ACE は、Apsara File Storage NAS NFS ファイルシステムでは使用されません。 ファイルシステムの監査は Apsara File Storage NAS コンソールを使用して実施し、監査結果に基づいてアラートを設定します。
- ファイルまたはディレクトリに ACL が指定されていない場合、ファイルまたはディレクトリに対して事前に定義されたモードに対応するデフォルトの ACL が適用されます。
touch file
[root@vbox test]# ls -l file -rw-r--r--. 1 root root 0 May 6 14:27 file
[root@vbox test]# nfs4_getfacl file # file: file A::OWNER@:rwatTnNcCy A::GROUP@:rtncy A::EVERYONE@:rtncy
- ACL は、ACE を順番に記述したもので、重複する ACE は取り除かれます。 この方法により、ACL に権限を明確かつ正しく定義することができます。
同じオブジェクトに新しい ACE と既存の ACE を適用し、既存の ACE が親オブジェクトから継承される場合、新しい ACE の権限は既存の ACE の権限に優先します。 例:
- ACE が順番に記述された ACL では、OWNER@、GROUP@、およびEVERYONE@ のプリンシパルを含む ACE が順番にキューに入れられ、他の ACE
より優先されます。
[root@vbox test]# nfs4_getfacl file # file: file A::OWNER@:rwaxtTnNcCy A::GROUP@:rtncy A::EVERYONE@:rtncy A::1001:rwaxtTNcCy
- 名前が 1009 のユーザープリンシパルの次の ACL に読み取りおよび書き込み権限の ACE を追加します。 ACE は、定義済みの順序に基づいて 、名前が 1001
のユーザープリンシパルに定義されている ACE の後に配置されます。
[root@vbox test]# nfs4_setfacl -a A::1009:X file [root@vbox test]# nfs4_getfacl file # file: file A::OWNER@:rwaxtTcCy A::GROUP@:rwatcy A::EVERYONE@:tcy A::1001:rwaxtTNcCy A::1009:xtcy
- ACL に実行権限を含む新しい ACE を追加します。 システムは、名前が 1009 のユーザープリンシパルの既存の ACE に実行権限を自動的にマージします。
[root@vbox test]# nfs4_setfacl -a A::1009:W file [root@vbox test]# nfs4_getfacl file # file: file A::OWNER@:rwaxtTcCy A::GROUP@:rwatcy A::EVERYONE@:tcy A::1001:rwaxtTNcCy A::1009:waxtTncCy
- 名前が 1009 のユーザープリンシパルを含む ACE に f および d 継承フラグを追加すると、システムは ACE を 2 つの ACE に分割します。 1 つの
ACE には、i という名前の追加の継承フラグが指定されています。これは、継承のみの ACE を示します。 もう 1 つの ACE は、継承フラグのないファイルオブジェクトにのみ適用されます。
既存の ACE の継承タイプが 2 つの ACE のいずれかのタイプと一致する場合、システムは既存の ACE を 2 つの ACE からの ACE と結合します。
一致する 2 つの ACE は 1 つの ACE に変換されます。
[root@vbox test]# nfs4_setfacl -a A:fd:1009:R file [root@vbox test]# nfs4_getfacl file # file: file A::OWNER@:rwaxtTcCy A::GROUP@:rwatcy A::EVERYONE@:tcy A::1001:rwaxtTNcCy A::1009:rwaxtTNcCy A:fdi:1009:r
- ACE が順番に記述された ACL では、OWNER@、GROUP@、およびEVERYONE@ のプリンシパルを含む ACE が順番にキューに入れられ、他の ACE
より優先されます。
- ACE のすべての権限は継承可能です。
- たとえば、OWNER@ プリンシパルには書き込みアクセス権があり、GROUP@ プリンシパルには読み取りアクセス権があり、EVERYONE@ には dir ディレクトリへのアクセス権がありません。
[root@vbox nfs]#nfs4_getfacl dir # file: dir A::OWNER@:rwaDxtTnNcCy A::GROUP@:rxtcy A::EVERYONE@:tncy
- 名前が 1000 のユーザープリンシパルに、dir ディレクトリへの読み取り、書き込み、および実行アクセスを許可する ACE を追加します。 ACE には、f および
d 継承フラグも指定されています。
[root@vbox nfs]# nfs4_setfacl -a A:fd:1000:rwx dir [root@vbox nfs]# nfs4_getfacl dir # file: dir A::OWNER@:rwaDxtTcCy A::GROUP@:rxtcy A::EVERYONE@:tcy A::1000:rwx A:fdi:1000:rwx
- dir ディレクトリにファイルまたはサブディレクトリを作成すると、ファイルまたはサブディレクトリは、dir ディレクトリからすべての ACE を自動的に継承します。
[root@vbox nfs]# touch dir/file [root@vbox nfs]# nfs4_getfacl dir/file # file: dir/file A::OWNER@:rwatTcCy A::GROUP@:rwatcy A::EVERYONE@:rwatcy A::1000:rwx
[root@vbox nfs]# mkdir dir/subdir [root@vbox nfs]# nfs4_getfacl dir/subdir # file: dir/subdir A::OWNER@:rwaDxtTcCy A::GROUP@:rwaDxtcy A::EVERYONE@:rwaDxtcy A:fdi:1000:rwx
注- EVERYONE@ プリンシパルに付与する権限は最小限にすることを推奨します。 次の手順を実行する前に、
umask 777
コマンドを実行することを推奨します。 このコマンドは、ファイルまたはディレクトリの作成時にファイルまたはディレクトリへのアクセスが許可されないようにします。 詳細については、「Why doesn't umask change execute permissions on files? [duplicate]」をご参照ください 。 - Linux が関数を呼び出してファイルまたはディレクトリを作成する場合、定義済みのファイルモード作成マスクがリクエストパラメーターとして使用されます。 RFC7530標準で明示されているように、子オブジェクトの最終的な ACL は、継承された ACL (親から子) とファイルモード作成マスクで重複する部分から取得できます。 標準に基づいてファイルモード作成マスクのグループビットを変更する場合、各グループの ACL に含まれる権限は、グループビットで定義された権限以下でなければなりません。 この方法では、グループの無効な継承が発生します。 たとえば、ファイルを作成する際、ファイルは親オブジェクトから A:RWX を継承しようとします。 ただし、事前定義されたファイルモード作成マスクはグループビットを R に設定します。ファイルの最終的な権限は A:R になります。実際の運用では、OWNER@、GROUP@、および EVERYONE@ を含むプリンシパルを含む ACL のファイルモード作成マスクのみを変更することを推奨します。 これにより、潜在的な問題が回避され、セマンティクスが明確になります。 グループのアクセス権限を削除するには、グループに関連する ACE のみを削除する必要があります。
- たとえば、OWNER@ プリンシパルには書き込みアクセス権があり、GROUP@ プリンシパルには読み取りアクセス権があり、EVERYONE@ には dir ディレクトリへのアクセス権がありません。
- 複数の独立したインスタンス間で、ユーザー名またはグループ名と、UID または GID の間のマッピングを維持する必要があります。
Apsara File Storage NAS NFS は、ユーザーの認証にユーザー名ではなく IP セキュリティグループを採用しています。 NFSv4 ACL を設定すると、ACE に含まれる UID または GID が Linux に保存されます。 シェルでオブジェクトの ACL を出力すると、Linux は自動的に /etc/passwd ファイルをロードし、UID または GID を実際のユーザー名またはグループ名に変換します。 ユーザー名またはグループ名と、複数のインスタンス間の UID または GID との間のマッピングを維持する必要があります。 ユーザー名またはグループ名が関連する UID または GID にマップされていることを確認する必要があります。
- NFSv4 ACL は、拡張属性を使用して出力できます。
[root@vbox nfs]# getfattr -n system.nfs4_acl file # file: file system.nfs4_acl=0sAAAABgAAAAAAAAAAABYBhwAAAAZPV05FUkAAAAAAAAAAAAAAABIAhwAAAAZHUk9VUEAAAAAAAAAAAAAAABIAhwAAAAlFVkVSWU9ORUAAAAAAAAAAAAAAAAAAAAEAAAAEMTAwMAAAAAAAAAALAAAAAwAAAAQxMDAwAAAAAAAAAEAAFgGQAAAABTEwMDAxAAAA
- NFSv4 ACL の移行では、cp などのツールがサポートされています。
Apsara File Storage NAS は、cp、tar、および rsync ツールをサポートして、NFSv4 ACL を移行します。 詳細については、「How to preserve NFS v4 ACLs via extended attributes when copying file」 をご参照ください。
コマンドcp --preserve=xattr file1 file2
コマンドは、file 1 のコピーとして file2 を作成します。その際、file1 の ACL が file2 にコピーされます。 コマンドcp -ar dir1 dir2
は、dir1 のコピーとして dir2 を作成します。その際、dir1 の ACL は dir2 にコピーされます。注 rsync ツールのバージョンが 3.1.2 未満の場合、NFSv4 ACL の移行に失敗する場合があります。[root@vbox nfs]# nfs4_getfacl file1 # file: file1 A::OWNER@:rwatTcCy A::GROUP@:rwatcy A::EVERYONE@:rwatcy A::1000:rtncy [root@vbox nfs]# cp --preserve=xattr file1 file2
[root@vbox nfs]# nfs4_getfacl file2 # file: file2 A::OWNER@:rwatTcCy A::GROUP@:rwatcy A::EVERYONE@:rwatcy A::1000:rtncy [root@vbox nfs]# cp -ar dir1 dir2
- NFSv4 とファイルモード作成マスク間の相互運用がサポートされています。 オブジェクトの ACL を変更すると、オブジェクトのファイルモード作成マスクが変更される場合があります。
オブジェクトのファイルモード作成マスクを変更すると、オブジェクトの ACL が変更される場合があります。
たとえば、ファイルオブジェクトのファイルモード作成マスクは 0666 です。
[root@vbox nfs]# ls -l file -rw-rw-rw-。 1 root root 0 May 3 2019 file [root@vbox nfs]# nfs4_getfacl file # file: file A::OWNER@:rwatTcCy A::GROUP@:rwatcy A::EVERYONE@:rwatcy
- 所有者ビットを変更してファイルモード作成マスクに実行権限を追加すると、OWNER@ プリンシパルを含む ACE にも実行権限が追加されます。
[root@vbox nfs]# chmod u+x file [root@vbox nfs]# ls -l file -rwxrw-rw-. 1 root root 0 May 3 2019 file [root@vbox nfs]# nfs4_getfacl file # file: file A::OWNER@:rwaxtTcCy A::GROUP@:rwatcy A::EVERYONE@:rwatcy
- GROUP@ プリンシパルを含む ACE に実行権限を追加すると、関連するファイルモード作成マスクにも実行権限が追加されます。
[root@vbox nfs]# nfs4_setfacl -a A::GROUP@:x file [root@vbox nfs]# ls -l file -rwxrwxrw-. 1 root root 0 May 3 2019 file
注- ACL とファイルモード作成マスクの相互作用では、EVERYONE@ プリンシパルは他のクラスと同等です。 他のクラスを変更すると、変更は EVERYONE@ プリンシパルにも適用されます。
この操作は、アクセス権限のセマンティクスにわずかな影響を与えます。 たとえば、現在のファイルモード作成マスクは 177 です。 コマンド
chmod o+r
を実行すると、ファイル所有者とグループメンバーを含むすべてのユーザーに読み取り権限が付与されます。 これは、EVERYONE@ プリンシパルを含む関連 ACE に読み取り権限が追加されるためです。 デフォルトのファイルモード作成マスクに変更が適用されていない場合、コマンド chmod o+r を実行した後も、所有者とグループクラスには読み取り権限は付与されません。 - NFSv4 ACL に変更が適用されない場合、ファイルモード作成マスクの他のクラスは同じセマンティクスを保持します。 NFSv4 ACL が変更されると、others クラスのセマンティクスは EVERYONE@ プリンシパルのセマンティクスに変更され、セマンティクスが保持されます。 NFSv4 ACL を使用した後は、ファイルモード作成マスクを使用しないことを推奨します。
- 所有者ビットを変更してファイルモード作成マスクに実行権限を追加すると、OWNER@ プリンシパルを含む ACE にも実行権限が追加されます。
- NFSv4 ACL と POSIX ACL 間の相互作用がサポートされています。
NFSv3 プロトコルを使用して、NFSv4 ACL が適用されたファイルシステムをマウントできます。 これらの NFSv4 ACL は、POSIX ACL に変換されます。 NFSv4 プロトコルを使用して、POSIX ACL が適用されたファイルシステムをマウントすることもできます。 これらの POSIX ACL は、NFSv4 ACL に変換されます。
注 POSIX ACL のセマンティクスは、NFSv4 ACL のセマンティクスとは異なります。 たとえば、POSIX ACL に適用される継承ルールは、ファイルとディレクトリを区別しません。 NFSv4 ACL には、読み取り、書き込み、実行の権限のみを持つ POSIX ACL よりも多様な権限があります。 潜在的な問題を防ぐために、NFSv4 ACL または POSIX ACL を使用することを推奨します。たとえば、ディレクトリ dir0 の NFSv4 ACL を設定します。 権限は以下のとおりです。
[root@vbox test] sudo nfs4_getfacl dir0 A::OWNER@:tTnNcCy A::GROUP@:tncy A::EVERYONE@:tncy A:fdi:EVERYONE@:tncy A:fdi:OWNER@:tTnNcCy A:fdi:GROUP@:tncy A:g:19064:rxtncy A:g:19065:rwaDxtTnNcCy A:fdig:19064:rxtncy A:fdig:19065:rwaDxtTnNcCy
dir0 ディレクトリの POSIX ACL を設定します。 権限は以下のとおりです。
[root@vbox test] sudo getfacl dir0 user::--- group::--- group:players:r-x group:adminis:rwx mask::rwx other::--- default:user::--- default:group::--- default:group:players:r-x default:group:adminis:rwx default:mask::rwx default:other::---
たとえば、dir0/file ファイルの NFSv4 ACL を設定します。 権限は以下のとおりです。
[root@vbox test] sudo nfs4_getfacl dir0/file A :: OWNER@:tTnNcCy A :: GROUP@:tncy A :: EVERYONE@:tncy A:g:19064:rxtncy A:g:19065:rwaxtTnNcCy
dir0/file ファイルの POSIX ACL を設定すると仮定します。 権限は以下のとおりです。
[root@vbox test] sudo getfacl dir0/file user::--- group::--- group:players:r-x group:adminis:rwx mask::rwx other::---
- NFSv4 ACL 数の上限について。
Apsara File Storage NAS では、ファイルシステムごとに内容が異なるACLを 100,000 個まで作成できます。 各 ACL には、最大 500 個の ACE を記述できます。注 ACL と ACE は正しく使用することを推奨します。 アクセス権限の確認にかかる時間とリソースを削減できます。
Apsara File Storage NAS POSIX ACL の機能
- 他のクラスに指定された権限は、すべてのクラスに適用されます。
全員には、各 ACE に関連する所有者、グループ、およびユーザーが含まれます。 もう 1 つのクラスは、NFSv4 ACL の EVERYONE@ プリンシパルと同等です。
注 すべての場合において、他のクラスに最小限の権限を付与することを推奨します。たとえば、以下の ACL がファイルmyfile に設定されているとします。 ACE には書き込み権限のない alice という名前のユーザーが含まれていますが、他のクラスに権限が指定されているため、書き込み権限は ACE に伝達されます。
[root@vbox 3]# getfacl myfile # file: myfile # owner: root # group: root user::rw- user:alice:r-- group::r-- mask::r-- other::rw-
- ACL によって設定されたアクセス権限は、
chmod
コマンドを実行しても変更されません 。注 POSIX ACL が適用されているファイルのファイルモード作成マスクは変更しないことを推奨します。 POSIX ACL を変更することにより、ファイルのアクセス権限を設定できます。- たとえば、グループ players にファイル myfile への読み取りおよび書き込みアクセスを許可するACEがあるとします。
[root@vbox 3]# getfacl myfile # file: myfile # owner: root # group: root user::rw- user:player:rw- group::rw- group:players:rw- mask::rw- other::---
- コマンド
chmod g-w myfile
またはchmod u-w myfile
では、player ユーザーと players グループに付与されるアクセス権限は変更されません。この点は、POSIX ACL standard と異なります。 ただし、POSIX ACL によって非予約ユーザーに付与されるアクセス権限は、ファイルモード作成マスクを使用してアクセス権限を変更した後も変わりません。 予約されていないユーザーには、所有者、グループ、およびその他のクラスのユーザーを除くすべてのユーザーが含まれます。[root@vbox 3]# getfacl myfile # file: myfile # owner: root # group: root user::r-- user:player:rw- group::r-- group:players:rw- mask::rw- other::---
- たとえば、グループ players にファイル myfile への読み取りおよび書き込みアクセスを許可するACEがあるとします。
- 実行権限がグループおよび ACL の他のクラスに付与されていない場合、ACL には実行権限がありません。
ルールは Linux で事前定義されています。 実行アクションは、Apsara File Storage NAS のバックエンドによって許可されます。 ただし、ACL の実行権限を有効にするには、グループまたは他のクラスに実行権限を付与する必要があります。
たとえば、グループおよび他のクラスにファイル myfile の実行アクセス権がない場合 、player ユーザーはファイルを実行できません。
[root@vbox 3]# getfacl myfile # file: myfile # owner: root # group: root user::rw- user:player:r-x group::r-- mask::r-x other::r--
グループクラスに実行権限を付与すると、実行権限も player ユーザーに伝達されます。[root@vbox 3]# getfacl myfile # file: myfile # owner: root # group: root user::rw- user:player:r-x group::r-x mask::r-x other::r--
- ディレクトリに対して継承が可能な NFSv4 ACL を設定すると、NFSv3 ファイルシステムのディレクトリについては POSIX ACL 標準非準拠の設定となる可能性があります。
ファイルに適用される継承ルールは、NFSv4 ACL のディレクトリに適用されるルールとは異なります。 POSIX ACL のファイルとディレクトリの両方に同じ継承規則が適用されます。
注 問題の発生事前に防止するため、NFS4 ACL または POSIX ACL を NFS ファイルシステムに適用することを推奨します。 - ファイルモード作成マスクの変更はサポートしていません。
POSIX ACL のファイルモード作成マスクは、すべてのユーザーおよびグループのアクセス権限の組み合わせおよび相互関係に基づいて作成されます。 マスクには実用的な意味はなく、変更できません。
- ユーザー名またはグループ名と、 UID または GID との間のマッピングを複数インスタンス間で維持する必要があります。
Apsara File Storage NAS NFS は、ユーザー認証にユーザー名ではなく IP セキュリティグループを採用しています。 POSIX ACL を設定すると、ACE に含まれる UID または GID は Linux に保存されます。 シェル内のオブジェクトの ACL を出力すると、Linux は自動的に/etc/passwd ファイルを読み込み、UID または GID を実際のユーザー名またはグループ名に変換します。 ユーザー名またはグループ名と、 UID または GID との間のマッピングを複数インスタンス間で維持する必要があります。 ユーザー名またはグループ名が、関連する UID または GID にマップされていることを確認する必要があります。
- 拡張属性を使用した POSIX ACL の出力をサポートします。
[root@vbox nfs]# getfattr -n system.posix_acl_access file # file: file system.posix_acl_access=0sAgAAAAEAAAD/////AgAFACAEAAAEAAAA/////xAABQD/////IAABAP////8=
- cp などのツールを使用した POSIX ACL の移行をサポートします。
Apsara File Storage NAS は、cp、tar、および rsync ツールを使用した POSIX ACL の移行をサポートしています。 詳細については、「How to preserve NFS v4 ACLs via extended attributes when copying file」をご参照ください。
コマンドcp --preserve=xattr file1 file2
は、 file1 を file2 として作成します。その際、 file1 の ACL が file2 にコピーされます。 コマンドcp -ar dir1 dir2
は、dir1 のコピーを dir2 として作成します。その際 dir1 の ACL が dir2 にコピーます。注 rsync ツールのバージョンが 3.1.2 未満の場合、POSIX ACL の移行に失敗する場合があります。[root@vbox nfs]# getfacl file1 user::--- user:player:r-x group::--- mask::r-x other::--x [root@vbox nfs]# cp --preserve=xattr file1 file2
[root@vbox nfs]# getfacl file2 # file: file2 user::--- user:player:r-x group::--- mask::r-x other::--x [root@vbox nfs]# cp -ar dir1 dir2
- POSIX ACL 数の上限。
Apsara File Storage NAS では、ファイルシステムごとに内容が異なるACLを 100,000 個まで作成できます。 各 ACL には、最大 500 個の ACE を記述できます。注 ACL と ACE は正しく使用することを推奨します。 アクセス権限の確認にかかる時間とリソースを削減できます。
よくある質問
- ACL 内では、ACE の位置が重要な意味を持つためです。
NFSv4 ACL に存在する ACE の順序はランダムです。 タイプが deny の ACE は、NFSv4 ACL の任意の位置に配置できます。 たとえば、ACL には A::Alice:r と D::Alice:r の 2 つの ACE が記述されているとします。 ACE の位置は、ユーザー Alice に書き込み権限が付与されるかどうかを決定します。
注 ACL を設定する際は、各 ACE の位置を考慮する必要があります。 - ACL 内の ACE の数が急激に増加するためです。
ACE の順序付けは必須ではないため、ACL で ACE を結合したり、ACE の重複を排除することが困難となる場合があります。 ACE の数は、長い期間が経過すると数 10 または数 100 まで増加する場合があります。 これらの ACE によって生成される最終的なアクセス権限を管理するには、それぞれの ACE を確認する必要があります。 チェックには手間と時間が必要です。
- ファイルモード作成マスクには拒否の機能がないため、Type が deny の ACE が適用されると、ファイルモード作成マスクと ACL 間の相互作用はより複雑化します。
- タイプが deny ACE が使用可能な場合、ファイルモード作成マスクが変更された際に、ACL にいくつかの ACE を追加する必要がある場合があります。 たとえば、ファイルモード作成マスクを
-rw-rw-rw に変更する場合、次の ACE を ACL に追加する必要があります。 ACL の先頭に ACE を順番に追加する必要があります。
A::OWNER@:rw D::OWNER@:x A::GROUP@:rw D::GROUP@:x A::EVERYONE@:rw D::EVERYONE@:x
- タイプが deny の ACE が利用できない場合、ACE を順に記述して重複を排除できます。 EVERYONE@ プリンシパルと他のクラスを区別する必要はありません。
ファイルモード作成マスクが変更された場合、ACL を簡単に変更できます。 OWNER@、GROUP@、および EVERYONE@ プリンシパルを含む ACE を検索し、これらの
ACE を次のように変更するだけで済みます。
A::OWNER@:rw A::GROUP@:rw A::EVERYONE@:rw
- タイプが deny ACE が使用可能な場合、ファイルモード作成マスクが変更された際に、ACL にいくつかの ACE を追加する必要がある場合があります。 たとえば、ファイルモード作成マスクを
-rw-rw-rw に変更する場合、次の ACE を ACL に追加する必要があります。 ACL の先頭に ACE を順番に追加する必要があります。
- NFSv4 ACL と POSIX ACL 間の変換はサポートされていません。
POSIX ACL は、タイプが deny の ACE をサポートしていません。 1 つ以上の deny ACE が NFSv4 ACL に記述されている場合、ACL は POSIX ACL に変換できません。