瞭解 Azure NetApp Files 中的 NFSv4.x 存取控制清單
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 Files 支援存取、拒絕和稽核等 ACL 類型,但稽核 ACL 雖然能夠設定,但目前不會產生稽核記錄。
- 旗標:為 ACL 新增額外的內容。 ACE 旗標有三種:群組、繼承和管理。 如需旗標的詳細資訊,請參閱 NFSv4.x ACE 旗標 (部分機器翻譯)。
- 主體:定義指派 ACL 的使用者或群組。 NFSv4.x ACL 上的主體會使用 name@ID-DOMAIN-STRING.COM 的格式。 如需主體的詳細資訊,請參閱 NFSv4.x 使用者和群組主體 (部分機器翻譯)。
- 權限:定義主體存取層級。 每個權限都會指定單一字母 (例如,「讀取 (read)」會取得「r」、「寫入 (write)」會取得「w」,依此類推)。 完整存取權會納入每個可用的權限字母。 如需詳細資訊,請參閱 NFSv4.x 權限 (部分機器翻譯)。
A:g:group1@contoso.com:rwatTnNcCy
是遵循 type:flags:principal:permissions
格式的一個有效 ACL 的範例。 範例 ACL 會授與 contoso.com 識別碼網域中群組 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,則拒絕是隱含的。 拒絕 ACL 可能會對於 ACL 管理造成不必要的複雜問題。
繼承旗標
繼承旗標可在父目錄下建立且已設定繼承旗標的檔案上控制 ACL 的行為。 設定繼承旗標時,檔案和/或目錄會從父資料夾繼承 ACL。 繼承旗標只能套用至目錄,因此在建立子目錄時會繼承旗標。 在具有繼承旗標的父目錄下建立的檔案會繼承 ACL,但不會繼承旗標。
下表將說明可用的繼承旗標及其行為。
繼承旗標 | 行為 |
---|---|
d | - 父目錄下的目錄會繼承 ACL - 也會繼承繼承旗標 |
f | - 父目錄下的檔案會繼承 ACL - 檔案不會設定繼承旗標 |
i | 僅限繼承;ACL 不適用於目前的目錄,但必須將繼承套用至目錄下的物件 |
n | - 不會傳播繼承 繼承 ACL 之後,父代下的物件上會清除繼承旗標 |
NFSv4.x ACL 範例
在下列範例中,有三個不同的 ACE,分別具有不同的繼承旗標:
- 僅繼承目錄 (di)
- 僅繼承檔案 (di)
- 檔案與目錄皆繼承 (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,但在父代下的檔案上則不會。
# 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 上設定「不傳播」(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 Files 支援 設定 稽核 ACE 的管理旗標,但 ACE 無法運作。 此外,Azure NetApp Files 不支援警示 ACE。
NFSv4.x 使用者和群組主體
使用 NFSv4.x ACL 時,使用者和群組主體會定義 ACE 應套用的特定物件。 主體通常會遵循 name@ID-DOMAIN-STRING.COM 的格式。 主體的「名稱」部分可以是使用者或群組,但在指定NFSv4.x 識別碼網域時,必須可以在 Azure NetApp Files 中透過 LDAP 伺服器連線解析該使用者或群組。 如果 Azure NetApp Files 無法解析 name@domain,則 ACL 作業會發生失敗,並出現「引數無效」的錯誤。
# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument
您可以在 Azure NetApp Files 內檢查是否可以使用 LDAP 群組識別碼清單解析名稱。 瀏覽至支援 + 疑難排解和 LDAP 群組識別碼清單。
透過 NFSv4.x ACL 進行存取的本機使用者和群組
只有在 ACL 中指定數值識別碼時,才能在 NFSv4.x ACL 上使用本機使用者和群組。 指定網域識別碼的使用者名稱或數值識別碼發生失敗。
例如:
# 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 上數值識別碼的任何使用者或群組都會接收物件的存取權。 針對本地群組 ACL,使用者會將其群組成員資格傳遞給 Azure NetApp Files。 如果透過使用者要求存取檔案之群組的數值識別碼會向 Azure NetApp Files NFS 伺服器顯示,則系統會根據 ACL 允許存取。
從用戶端傳遞至伺服器的認證可以透過封包擷取進行查看,如下所示。
警示:
- 若將本機使用者和群組用於 ACL,表示每個存取檔案/資料夾的用戶端都必須有相符的使用者和群組識別碼。
- 若將數值識別碼用於 ACL,則 Azure NetApp Files 會以隱含方式信任傳入要求為有效,而要求存取的使用者符合他們表明的身分,而且屬於他們宣告的群組中。 如果惡意執行者知道數值識別碼,且可以使用用戶端在本機建立使用者和群組並存取網路,則使用者或群組數值可能會遭竄改。
- 如果使用者屬於 16 個以上的群組,則除非使用 LDAP 和擴充群組支援,否則第十六個群組之後的任何群組 (以英數字元排序) 之檔案或資料夾存取會遭到拒絕。
- 使用 NFSv4.x ACL 提升可管理性和安全性時,強烈建議使用 LDAP 和完整 name@domain 名稱字串。 集中管理的使用者和群組存放庫較易於維護且更難遭竄改,因此較不易讓不必要的使用者進行存取。
NFSv4.x 識別碼網域
識別碼網域是主體的重要元件,其中識別碼網域必須符合用戶端和 Azure NetApp Files 中的使用者和群組名稱 (特別是根),才能正確顯示其檔案/資料夾擁有權。
Azure NetApp Files 會預設將磁碟區的 DNS 網域設定設為 NFSv4.x 識別碼網域。 NFS 用戶端也會預設將 DNS 網域設為 NFSv4.x 識別碼網域。 如果用戶端的 DNS 網域與 Azure NetApp Files DNS 網域不同,則會發生不相符的情況。 使用 ls
等命令列出檔案權限清單時,使用者/群組會顯示為「nobody」。
若 NFS 用戶端與 Azure NetApp Files 之間發生網域不符,請檢查用戶端記錄是否有類似下列錯誤:
August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'
您可以使用 /etc/idmapd.conf 檔案的「網域」設定來覆寫 NFS 用戶端的識別碼網域。 例如: Domain = CONTOSO.COM
。
Azure NetApp Files 也可讓您變更 NFSv4.1 識別碼網域。 如需其他詳細資訊,請參閱操作說明:適用於 Azure NetApp Files 的 NFSv4.1 識別碼網域設定。
NFSv4.x 權限
NFSv4.x 權限是控制特定使用者或群組主體在檔案或資料夾上具有何種存取層級的方式。 NFSv3 中的權限只允許讀取/寫入/執行 (rwx) 層級的存取定義,然而 NFSv4.x 提供大量其他精確的存取控制,可改善 NFSv3 模式位元。
您可以為使用者設定 13 個權限,以及可以針對群組設定的 14 個權限。
權限字母 | 已授與權限 |
---|---|
r | 讀取資料/清單檔案和資料夾 |
w | 寫入資料/建立檔案和資料夾 |
a | 附加資料/建立子目錄 |
x | 執行檔案/周遊目錄 |
d | 刪除檔案/目錄 |
D | 刪除子目錄 (僅限目錄) |
t | 讀取屬性 (GETATTR) |
T | 寫入屬性 (SETATTR/chmod) |
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 (waxtTNcy) |
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 Files 使用
若磁碟區已啟用 NFSv4.1 進行存取,Azure NetApp Files 會以原生方式支援 NFSv4.x ACL。 ACL 支援磁碟區上沒有任何項目可啟用,但為了讓 NFSv4.1 ACL 能夠以最佳方式運作,則需要具有 UNIX 使用者和群組的 LDAP 伺服器,以確保 Azure NetApp Files 能夠安全解析 ACL 上設定的主體。 本機使用者可與 NFSv4.x ACL 搭配使用,但無法提供與 LDAP 伺服器搭配使用之 ACL 相同的安全性層級。
請留意 Azure NetApp Files 中的 ACL 功能等考量因素。
ACL 繼承
在 Azure NetApp Files 中,ACL 繼承旗標可用來搭配 NFSv4.x ACL 使用以簡化 ACL 管理工作。 設定繼承旗標時,父目錄上的 ACL 可以傳播至子目錄和檔案,而不需進一步互動。 Azure NetApp Files 會根據 RFC-7530 實作標準 ACL 繼承行為。
拒絕 ACE
Azure NetApp Files 中的拒絕 ACE 可用來明確限制使用者或群組存取檔案或資料夾。 您可以定義權限子集,對拒絕 ACE 的進行精確控制。 以上會以 RFC-7530 中所述的標準方法運作。
ACL 保留
若 chmod 在 Azure NetApp Files 中的檔案或資料夾上執行時,所有現有的 ACL 都會保留在系統 ACE 以外的 ACL 上 (OWNER@, GROUP@, EVERYONE@)。 這些 ACE 權限會按照數值模式位元的定義修改,而數值模式位元則會依 chmod 命令所定義。 只有透過 nfs4_setfacl
命令手動修改或移除的ACE 可以變更。
雙重通訊協定環境中的 NFSv4.x ACL 行為
雙重通訊協定是指在同一個 Azure NetApp Files 磁碟區上使用 SMB 和 NFS 的情形。 雙重通訊協定之存取控制取決於磁碟區所使用的安全性樣式,但使用者名稱對應功能可確保成功對應至彼此的 Windows 使用者和 UNIX 使用者具有相同的資料存取權縣。
在 UNIX 安全性樣式磁碟區上使用 NFSv4.x ACL 時,可以在使用雙重通訊協定磁碟區並從 SMB 用戶端存取資料時觀察到下列行為。
- Windows 使用者名稱必須正確對應至 UNIX 使用者名稱,才能進行適當的存取控制解析。
- 在 UNIX 安全性樣式磁碟區中 (套用 NFSv4.x ACL),如果 LDAP 伺服器中沒有有效的 UNIX 使用者可供 Windows 使用者對應,則會對應名為
pcuser
(uid 數值 65534) 的預設 UNIX 使用者。 - 以 Windows 使用者寫入的檔案,若沒有有效的 UNIX 使用者對應,則會顯示為由數值識別碼 65534 所擁有的檔案,並會對應至 NFS 掛接之 Linux 用戶端中的「nfsnobody」或「nobody」使用者名稱。 這與 NFSv4.x 識別碼網域問題通常看到的數值識別碼 99 有所不同。 若要驗證使用中的數值識別碼,請使用
ls -lan
命令。 - 擁有者不正確的檔案將不會從 UNIX 模式位元或 NFSv4.x ACL 提供預期的結果。
- NFSv4.x ACL 可從 NFS 用戶端管理。 SMB 用戶端無法檢視和管理 NFSv4.x ACL。
使用 NFSv4.x ACL 之 Umask 影響
NFSv4 ACL 可提供 ACL 繼承的能力。 ACL 繼承表示使用 NFSv4 ACL 設定在物件之下建立的檔案或資料夾可以根據 ACL 繼承旗標的設定來繼承 ACL。
Umask 可用來控制檔案和資料夾在目錄中建立的權限層級。 根據預設,Azure NetApp Files 允許 umask 覆寫繼承的 ACL,這是根據 RFC-7530 的預期行為。
如需詳細資訊,請參閱 umask (部分機器翻譯)。
具有 NFSv4.x ACL 的 Chmod/chown 行為
在 Azure NetApp Files 中,您可以使用變更擁有權 (chown) 和變更模式位元 (chmod) 命令的方式來管理 NFSv3 和 NFSv4.x 上的檔案和目錄權限。
使用 NFSv4.x ACL 時,套用至檔案和資料夾的精確控制可減少 chmod 命令的需求。 Chown 仍有其用處,因為 NFSv4.x ACL 不會指派擁有權。
若 chmod 在套用 NFSv4.x ACL 的檔案和資料夾上於 Azure NetApp Files 中執行時,會在物件上變更模式位元。 此外,系統會修改一組系統 ACE,以反映這些模式位元。 如果系統 ACE 已移除,則系統會清除模式位元。 您可以在下列系統 ACE 的章節中找到其他範例與更完整的說明。
在 Azure NetApp Files 中執行 chown 時,可以修改指派的擁有者。 使用 NFSv4.x ACL 時,檔案擁有權不如使用模式位元時那麼重要,因為 ACL 可用來控制基本擁有者/群組/每個人概念無法控制的權限。 Azure NetApp Files 中的 Chown 只能以根身分執行 (以根身分或透過使用 sudo 執行),因為匯出控制已設定為僅允許根進行擁有權變更。 由於這是由 Azure NetApp Files 中的預設匯出原則規則所控制,因此不允許套用擁有權修改的 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 也可以用來精確限制根存取權。