你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
了解Azure NetApp 文档中的模式位
NFS 中的文件访问权限限制装载 NAS 卷后用户和组可以执行的操作。 模式位是 Azure NetApp 文档 中 NFS 文件权限的关键功能。
NFS 模式位
NFS 中的模式位权限使用访问控制的标准数字表示形式为文件和文件夹提供基本权限。 模式位可用于 NFSv3 或 NFSv4.1，但模式位是保护 RFC-1813 中定义的 NFSv3 的标准选项。 下表显示了这些数值如何与访问控制相对应。
| 模式位数字 |
|---|
| 1 – 执行 （x） |
| 2 – 写入 （w） |
| 3 – 写入/执行 （wx） |
| 4 – 读取（r） |
| 5 – 读取/执行（rx） |
| 6 – 读/写（rw） |
| 7 – 读/写/执行（rwx） |
数值应用于访问控制的不同段：所有者、组和其他人，这意味着基本 NFSv3 没有具体的用户访问控制。 下图显示了如何构造模式位访问控制以用于 NFSv3 对象的示例。
Azure NetApp 文档不支持 POSIX ACL。 因此，仅当通过 Active Directory LDAP 等名称服务使用具有有效 UNIX 到 Windows 名称映射的 NTFS 安全样式卷时，才能使用 NFSv3 精细 ACL。 或者，可以将 NFSv4.1 与 Azure NetApp 文档 和 NFSv4.1 ACL 配合使用。
下表比较了 NFSv3 模式位与 NFSv4.x ACL 之间的权限粒度。
| NFSv3 模式位 | NFSv4.x ACL |
|---|---|
|
|
有关详细信息，请参阅 了解 NFSv4.x 访问控制列表 ACL。
粘性位、setuid 和 setgid
将模式位与 NFS 装载一起使用时，文件和文件夹的所有权取决于uidgid创建文件和文件夹的用户。 此外，当进程运行时，它作为启动进程的用户运行，因此将具有相应的权限。 使用特殊权限（例如 setuid， setgid粘滞位），可以控制此行为。
Setuid
位 setuid 由权限所有者位的执行部分中的“s”指定。 位 setuid 允许可执行文件作为文件的所有者运行，而不是尝试执行该文件的用户。 例如，默认情况下， /bin/passwd 应用程序已启用 setuid 位，因此当用户尝试更改其密码时，应用程序将作为根运行。
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
setuid如果删除该位，密码更改功能将无法正常工作。
# ls -la /bin/passwd
-rwxr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: Authentication token manipulation error
passwd: password unchanged
setuid还原位后，passwd 应用程序将作为所有者（根）运行并正常运行，但仅适用于运行 passwd 命令的用户。
# chmod u+s /bin/passwd
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29 2022 /bin/passwd
# su user2
user2@parisi-ubuntu:/mnt$ passwd user1
passwd: You may not view or modify password information for user1.
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password:
New password:
Retype new password:
passwd: password updated successfully
Setuid 对目录没有影响。
Setgid
setgid位可用于文件和目录。
使用目录，setgid 可用作继承在父目录下创建且具有位集的文件和文件夹的所有者组的方法。 例如 setuid，可执行位更改为“s”或“S”。
注意
大写“S”表示尚未设置可执行位，例如，目录的权限为“6”或“rw”。
例如：
# chmod g+s testdir
# ls -la | grep testdir
drwxrwSrw- 2 user1 group1 4096 Oct 11 16:34 testdir
# who
root ttyS0 2023-10-11 16:28
# touch testdir/file
# ls -la testdir
total 8
drwxrwSrw- 2 user1 group1 4096 Oct 11 17:09 .
drwxrwxrwx 5 root root 4096 Oct 11 16:37 ..
-rw-r--r-- 1 root group1 0 Oct 11 17:09 file
对于文件，setgid 的行为类似于 setuid使用组所有者的组权限运行的可执行文件。 如果用户位于所有者组中，则表示用户在设置 setgid 时有权运行可执行文件。 如果他们不在组中，则无法访问。 例如，如果管理员想要限制哪些用户可以在客户端上运行 mkdir 命令，则可以使用 setgid。
通常， /bin/mkdir 具有 755 个具有根所有权的权限。 这意味着任何人都可以 mkdir 在客户端上运行。
# ls -la /bin/mkdir
-rwxr-xr-x 1 root root 88408 Sep 5 2019 /bin/mkdir
若要修改行为以限制用户可以运行 mkdir 命令的行为，请更改拥有 mkdir 应用程序的组，将权限 /bin/mkdir 更改为 750，然后将 setgid 位添加到 mkdir其中。
# chgrp group1 /bin/mkdir
# chmod g+s /bin/mkdir
# chmod 750 /bin/mkdir
# ls -la /bin/mkdir
-rwxr-s--- 1 root group1 88408 Sep 5 2019 /bin/mkdir
因此，应用程序使用权限 group1运行 。 如果用户不是其成员 group1，则用户无法访问运行 mkdir。
User1 是其 group1成员，但 user2 不是：
# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)
此更改后，user1可以运行mkdir，但无法运行，因为user2user2不存在group1。
# su user1
$ mkdir test
$ ls -la | grep test
drwxr-xr-x 2 user1 group1 4096 Oct 11 18:48 test
# su user2
$ mkdir user2-test
bash: /usr/bin/mkdir: Permission denied
粘滞位
粘滞位仅用于目录，并且使用时，无论其模式位权限如何，都可以在该目录中修改哪些文件。 设置粘滞位时，即使文件权限显示为“777”，只有文件所有者（和根）才能修改文件。
在以下示例中，目录“粘滞”位于 Azure NetApp Fils 卷中，并且具有广泛的开放权限，但已设置粘滞位。
# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt 2 root root 4096 Oct 11 19:24 sticky
文件夹中是不同用户拥有的文件。 全部具有 777 个权限。
# ls -la
total 8
drwxrwxrwt 2 root root 4096 Oct 11 19:29 .
drwxrwxrwx 8 root root 4096 Oct 11 19:24 ..
-rwxr-xr-x 1 user2 group1 0 Oct 11 19:29 4913
-rwxrwxrwx 1 UNIXuser group1 40 Oct 11 19:28 UNIX-file
-rwxrwxrwx 1 user1 group1 33 Oct 11 19:27 user1-file
-rwxrwxrwx 1 user2 group1 34 Oct 11 19:27 user2-file
通常，任何人都可以修改或删除这些文件。 但由于父文件夹设置了粘滞位，因此只有文件所有者才能对文件进行更改。
例如，user1 无法修改和删除 user2-file：
# su user1
$ vi user2-file
Only user2 can modify this file.
Hi
~
"user2-file"
"user2-file" E212: Can't open file for writing
$ rm user2-file
rm: can't remove 'user2-file': Operation not permitted
相反， user2 无法修改和删除 user1-file ，因为它们不拥有文件，粘滞位是在父目录中设置的。
# su user2
$ vi user1-file
Only user1 can modify this file.
Hi
~
"user1-file"
"user1-file" E212: Can't open file for writing
$ rm user1-file
rm: can't remove 'user1-file': Operation not permitted
但是，根仍可以删除文件。
# rm UNIX-file
若要更改根修改文件的能力，必须通过Azure NetApp 文档导出策略规则将根压到其他用户。 有关详细信息，请参阅 根壁球。
Umask
在 NFS 操作中，可以通过模式位控制权限，该模式位利用数字属性来确定文件和文件夹访问权限。 这些模式位确定读取、写入、执行和特殊属性。 从数字上看，权限表示为：
- 执行 = 1
- 读取 = 2
- 写入 = 4
总权限通过添加或减去上述组合来确定。 例如：
- 4 + 2 + 1 = 7 （可以执行所有操作）
- 4 + 2 = 6 （读/写）
有关详细信息，请参阅 UNIX 权限帮助。
Umask 是一项功能，允许管理员限制对客户端的权限级别。 默认情况下，大多数客户端的 umask 设置为 0022。 0022 表示从该客户端创建的文件被分配给 umask。 从对象的基权限中减去 umask。 如果卷具有 0777 权限，并且使用 NFS 装载到客户端，且 umask 为 0022，则从客户端写入到该卷的对象具有 0755 访问权限（0777 – 0022）。
# umask
0022
# umask -S
u=rwx,g=rx,o=rx
但是，许多操作系统不允许使用执行权限创建文件，但它们允许文件夹具有正确的权限。 因此，使用 umask 0022 创建的文件最终的权限可能为 0644。 以下示例使用 RHEL 6.5：
# umask
0022
# cd /cdot
# mkdir umask_dir
# ls -la | grep umask_dir
drwxr-xr-x. 2 root root 4096 Apr 23 14:39 umask_dir
# touch umask_file
# ls -la | grep umask_file
-rw-r--r--. 1 root root 0 Apr 23 14:39 umask_file