了解 Azure NetApp Files 中的模式位元
NFS 中的檔案存取權限會限制使用者和群組在裝載 NAS 磁碟區之後可執行的動作。 模式位元是 Azure NetApp Files 中 NFS 檔案存取權限的重要功能。
NFS 模式位元
NFS 中的模式位元存取權限使用存取控制的標準數值表示法，提供檔案和資料夾的基本存取權限。 模式位元可以搭配使用 NFSv3 或 NFSv4.1，但模式位元是保護 NFSv3 的標準選項，如 RFC-1813 中所定義。 下表顯示這些數值如何對應至存取控制。
| 模式位元數值 |
|---|
| 1 – 執行 (x) |
| 2 – 寫入 (w) |
| 3 – 寫入/執行 (wx) |
| 4 – 讀取 (r) |
| 5 – 讀取/執行 (rx) |
| 6 – 讀取/寫入 (rw) |
| 7 – 讀取/寫入/執行 (rwx) |
數值會套用至存取控制的不同區段：擁有者、群組及其他所有人，這表示基本 NFSv3 沒有細微的使用者存取控制。 下圖顯示的範例說明如何建構模式位元存取控制，以搭配使用 NFSv3 物件。
Azure NetApp Files 不支援 POSIX ACL。 因此，只有在搭配使用 NTFS 安全性樣式磁碟區與透過 Active Directory LDAP 等名稱服務進行有效的 UNIX 到 Windows 名稱對應時，才可能搭配使用細微 ACL 與 NFSv3。 或者，您可以使用 NFSv4.1 搭配 Azure NetApp Files 及 NFSv4.1 ACL。
下表比較 NFSv3 模式位元與 NFSv4.x ACL 之間的存取權限細微性。
| NFSv3 模式位元 | NFSv4.x ACLs |
|---|---|
|
|
如需詳細資訊，請參閱了解 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 應用程式會以擁有者 (根) 的身分執行並正常運作，但僅適用於執行 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，但 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 Files 匯出原則規則，將根壓縮到不同的使用者。 如需詳細資訊，請參閱壓縮根。
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