你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

了解 Azure NetApp 文件中的 NFSv4.x 访问控制列表

项目
02/19/2024

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 文件支持访问、拒绝和审核 ACL 类型，但审核 ACL 虽然能够设置，但目前不会生成审核日志。
标志 - 为 ACL 添加额外的上下文。有三种类型的 ACE 标志：组、继承和管理。有关标志的详细信息，请参阅 NFSv4.x ACE 标志。
主体 – 定义正在分配 ACL 的用户或组。 NFSv4.x ACL 上的主体使用 name@ID-DOMAIN-STRING.COM 格式。有关主体的详细信息，请参阅 NFSv4.x 用户和组主体。
权限 – 在其中定义了主体的访问级别。每个权限都指定一个字母（例如，读取为“r”，写入为“w”等）。完全访问权限将合并每个可用的权限字母。有关详细信息，请参阅 NFSv4.x 权限。

A:g:group1@contoso.com:rwatTnNcCy 是有效的 ACL 的示例，遵循 type:flags:principal:permissions 格式。示例 ACL 授予对 contoso.com ID 域中组 group1 的完全访问权限。

NFSv4.x ACE 标志

ACE 标志有助于提供有关 ACL 中 ACE 的详细信息。例如，如果将组 ACE 添加到 ACL，则需要使用组标志来指定主体是组而不是用户。在 Linux 环境中，可以有一个用户和一个组名称是相同的，因此标志可确保遵守 ACE，然后 NFS 服务器需要知道正在定义哪种类型的主体。

其他标志可用于控制 ACE，例如继承和管理标志。

访问和拒绝标志

访问 (A) 和拒绝 (D) 标志用于控制安全 ACE 类型。访问 ACE 控制主体对文件或文件夹的访问权限级别。拒绝 ACE 显式禁止主体访问文件或文件夹，即使设置了允许该主体访问对象的访问 ACE 也是如此。拒绝 ACE 始终优先于访问 ACE。通常，请避免使用拒绝 ACE，因为 NFSv4.x ACL 遵循“默认拒绝”模型，这意味着如果未添加 ACL，则拒绝是隐式的。拒绝 ACE 会给 ACL 管理带来不必要的麻烦。

继承标志

继承标志控制 ACL 针对父目录下创建且设置了继承标志的文件的行为方式。设置继承标志时，文件和/或目录从父文件夹继承 ACL。继承标志只能应用于目录，因此在创建子目录时，它将继承标志。在具有继承标志的父目录下创建的文件会继承 ACL，但不继承标志。

下表描述了可用的继承标志及其行为。

继承标志	行为
d	- 父目录下的目录继承 ACL - 继承标志也会继承
f	- 父目录下的文件继承 ACL - 文件未设置继承标志
i	仅继承；ACL 不适用于当前目录，但必须将继承应用于目录下的对象
n	- 不传播继承继承 ACL 后，在父级下方的对象上清除继承标志

NFSv4.x ACL 示例

在以下示例中，有三个不同的 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，但在父级下面的文件上，不会继承 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 时都无需显式设置 ACL。

管理标志

NFSv4.x ACL 中的管理标志是仅用于审核和警报 ACL 类型的特殊标志。这些标志定义要执行的操作的成功（S）或失败（F）访问尝试。

Azure NetApp 文件支持为审核 ACE 设置管理标志，但 ACE 不起作用。此外，Azure NetApp 文件中不支持警报 ACE。

NFSv4.x 用户和组主体

使用 NFSv4.x ACL，用户和组主体定义 ACE 要应用于的特定对象。主体通常遵循 name@ID-DOMAIN-STRING.COM 格式。主体的“name”部分可以是用户或组，但在指定 NFSv4.x ID 域时，该用户或组必须可通过 LDAP 服务器连接在 Azure NetApp 文件中解析。如果 Azure NetApp 文件无法解析 name@domain，则 ACL 操作将失败，并显示“无效参数”错误。

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

可以在 Azure NetApp 文件中检查是否可以使用 LDAP 组 ID 列表解析名称。导航到“支持 + 故障排除”，然后选择“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 文件。如果通过用户请求访问文件的组的数字 ID 显示给 Azure NetApp 文件 NFS 服务器，则系统会根据 ACL 允许访问。

可以通过数据包捕获来查看从客户端传输到服务器的凭据，如下所示。

注意：

对 ACL 使用本地用户和组意味着访问文件/文件夹的每个客户端都需要具有匹配的用户和组 ID。
对 ACL 使用数字 ID 时，Azure NetApp 文件隐式信任传入请求是否有效，并且请求访问的用户是他们所说的用户，并且是他们声称所属的组的成员。如果不良参与者知道数字 ID，并且可以使用客户端在本地创建用户和组，则可以欺骗用户或组数字。
如果用户是 16 个以上的组的成员，则第十六个组（以字母数字顺序）之后的任何组将被拒绝访问文件或文件夹，除非使用 LDAP 和扩展组支持。
强烈建议在使用 NFSv4.x ACL 时使用 LDAP 和完整的 name@domain 名称字符串，以提高可管理性和安全性。集中管理的用户和组存储库更易于维护和更难欺骗，从而减少了不必要的用户访问。

NFSv4.x ID 域

ID 域是主体的重要组成部分，其中 ID 域必须在客户端和 Azure NetApp 文件中匹配用户和组名称（特别是根），才能在文件/文件夹所有权上正确显示。

Azure NetApp 文件将 NFSv4.x ID 域默认为卷的 DNS 域设置。 NFS 客户端也默认为 NFSv4.x ID 域的 DNS 域。如果客户端的 DNS 域不同于 Azure NetApp 文件 DNS 域，则会发生不匹配。使用 ls 等命令列出文件权限时，用户/组将显示为“nobody”。

当 NFS 客户端与 Azure NetApp 文件之间发生域不匹配时，请检查客户端日志中是否存在类似于以下错误：

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

可以使用 /etc/idmapd.conf 文件的“域”设置重写 NFS 客户端的 ID 域。例如：Domain = CONTOSO.COM。

Azure NetApp 文件还允许更改 NFSv4.1 ID 域。有关其他详细信息，请参阅操作说明：适用于 Azure NetApp 文件的 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 (watTNcy)
4 – 读取 (r)	读取、读取属性、读取命名属性、读取 ACL、同步 I/O (rtncy)
5 – 读取/执行 (rx)	读取、执行、读取属性、读取命名属性、读取 ACL、同步 I/O (rxtncy)
6 – 读取/写入 (rw)	读取、写入、追加数据、读取属性、写入属性、读取命名属性、写入命名属性、读取 ACL、同步 I/O (rwatTnNcy)
7 – 读取/写入/执行 (rwx)	完全控制/所有权限

NFSv4.x ACL 如何使用 Azure NetApp 文件

当卷启用了 NFSv4.1 访问时，Azure NetApp 文件原生支持 NFSv4.x ACL。对于 ACL 支持，卷上没有启用任何功能，但对于 NFSv4.1 ACL，最好使用具有 UNIX 用户和组的 LDAP 服务器，以确保 Azure NetApp 文件能够安全地解析 ACL 上设置的主体。本地用户可与 NFSv4.x ACL 一起使用，但它们不提供与 LDAP 服务器一起使用的 ACL 相同的安全级别。

需要考虑 Azure NetApp 文件中的 ACL 功能。

ACL 继承

在 Azure NetApp 文件中，ACL 继承标志可用于使用 NFSv4.x ACL 简化 ACL 管理。设置继承标志后，父目录中的 ACL 可以传播到子目录和文件，而无需进一步交互。 Azure NetApp 文件根据 RFC-7530 实现标准 ACL 继承行为。

拒绝 ACE

Azure NetApp 文件中的拒绝 ACE 用于显式限制用户或组访问文件或文件夹。可以定义一部分权限，以提供对拒绝 ACE 的精细控制。这些方法在 RFC-7530 中提到的标准方法中运行。

ACL 保留

在 Azure NetApp 文件中的文件或文件夹上执行 chmod 时，所有现有 ACE 都会保留在系统 ACL（OWNER@、GROUP@、EVERYONE@）以外的 ACL 上。这些 ACE 权限由 chmod 命令定义的数值模式位定义进行修改。只能更改通过 nfs4_setfacl 命令手动修改或删除的 ACE。

双协议环境中的 NFSv4.x ACL 行为

双重协议是指在同一 Azure NetApp 文件卷上使用 SMB 和 NFS。双协议访问控制由卷所使用的安全样式确定，但用户名映射可确保成功映射到彼此的 Windows 用户和 UNIX 用户对数据具有相同的访问权限。

当 NFSv4.x ACL 在 UNIX 安全样式卷上使用时，在使用双协议卷和从 SMB 客户端访问数据时，可以观察到以下行为。

Windows 用户名需要正确映射到 UNIX 用户名，以便进行适当的访问控制解析。
在 UNIX 安全样式卷（其中将应用 NFSv4.x ACL）中，如果 LDAP 服务器中不存在有效的 UNIX 用户，Windows 用户要映射到该服务器，则将使用名为 pcuser 的默认 UNIX 用户（含 uid numeric 65534）进行映射。
使用 Windows 用户编写的文件没有有效的 UNIX 用户映射显示为数字 ID 65534 拥有的文件，对应于 NFS 装载中 Linux 客户端中的“nfsnobody”或“nobody”用户名。这不同于数字 ID 99，通常出现 NFSv4.x ID 域问题。若要验证正在使用的数字 ID，请使用 ls -lan 命令。
具有不正确所有者的文件不提供来自 UNIX 模式位或 NFSv4.x ACL 的预期结果。
NFSv4.x ACL 从 NFS 客户端进行管理。 SMB 客户端既不能查看也不能管理 NFSv4.x ACL。

Umask 对 NFSv4.x ACL 的影响

NFSv4 ACL 提供 ACL 继承的功能。 ACL 继承意味着在设置了 NFSv4 ACL 的对象下创建的文件或文件夹，可以基于 ACL 继承标志的配置继承 ACL。

Umask 用于控制在目录中创建文件和文件夹的权限级别。默认情况下，Azure NetApp 文件允许 umask 替代继承的 ACL，根据 RFC-7530 的预期行为。

有关详细信息，请参阅 umask。

NFSv4.x ACL 的 Chmod/chown 行为

在 Azure NetApp 文件中，可以使用更改所有权 (chown) 和更改模式位 (chmod) 命令来管理 NFSv3 和 NFSv4.x 上的文件和目录权限。

使用 NFSv4.x ACL 时，应用于文件和文件夹的更精细控件减少了 chmod 命令的需求。 Chown 仍然有一个位置，因为 NFSv4.x ACL 不分配所有权。

当 chmod 在应用了 NFSv4.x ACL 的文件和文件夹上的 Azure NetApp 文件中运行时，对象上的模式位会更改。此外，将修改一组系统 ACE 以反映这些模式位。如果删除了系统 ACE，则会清除模式位。有关示例和更完整的说明，请参阅下面的系统 ACE 部分。

在 Azure NetApp 文件中运行 chown 时，可以修改分配的所有者。使用 NFSv4.x ACL 时，文件所有权并不那么重要，就像使用模式位时一样，因为 ACL 可用于控制基本所有者/组/每个人概念无法控制的权限。 Azure NetApp 文件中的 Chown 只能作为根（根或 sudo）运行，因为导出控件配置为仅允许根更改所有权。由于此规则由 Azure NetApp 文件中的默认导出策略规则控制，因此不允许进行所有权修改的 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 模式 修改为“不受限制”。

修改后，除根用户具有适当的访问权限外，还可以更改所有权。这需要“获取所有权”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

删除系统 ACE 是进一步保护文件和文件夹的方法，因为只有 ACL（和根）上的用户和组主体可以访问该对象。删除系统 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 可用于精细限制根访问。

通过