了解 Azure NetApp 文件中的模式位

NFS 中的文件访问权限限制在装载 NAS 卷后用户和组可以执行的操作。 模式位是 Azure NetApp 文件中 NFS 文件权限的关键功能。

NFS 模式位

NFS 中的模式位权限使用访问控制的标准数字表示形式，为文件和文件夹提供基本权限。 模式位可用于 NFSv3 或 NFSv4.1，但模式位是保护 RFC-1813 中定义的 NFSv3 的标准选项。 下表显示了这些数值如何与访问控制相对应。

数值应用于访问控制的不同段：所有者、组和其他人，这意味着基本 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 之间的权限粒度。

有关详细信息，请参阅 了解 NFSv4.x 访问控制列表 ACL。

粘性位、setuid 和 setgid

将模式位与 NFS 装载一起使用时，文件和文件夹的所有权取决于创建文件和文件夹的用户的 uid 和 gid。 此外，当进程运行时，它作为启动进程的用户运行，因此将具有相应的权限。 使用特殊权限（例如 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 应用程序将作为所有者（root）运行并正常工作，但仅对执行 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”。

例如：

# 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 - 使用组所有者的组权限运行的executables。 如果用户位于所有者组中，则表示用户在设置 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，但user2无法运行，因为user2不在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

后续步骤

• 了解具有 NFS 的辅助/补充组
• 了解 NFSv4.x 访问控制列表