NFS
NFS 是一種分散式檔案系統協議,它是請求評論 (RFC) 中定義的開放 IETF 標準,允許任何人實現該協議。
Google Cloud NetApp Volumes中的磁碟區透過匯出用戶端或一組用戶端可存取的路徑共用給 NFS 用戶端。安裝這些匯出的權限由匯出原則和規則定義,可由Google Cloud NetApp Volumes管理員設定。
NetApp NFS 實施被認為是該協議的黃金標準,並應用於無數企業 NAS 環境。以下部分介紹Google Cloud NetApp Volumes中提供的 NFS 和特定安全功能及其實作方式。
預設本機 UNIX 使用者和群組
Google Cloud NetApp Volumes包含幾個用於各種基本功能的預設 UNIX 使用者和群組。目前無法修改或刪除這些使用者和群組。目前無法將新的本機使用者和群組新增至Google Cloud NetApp Volumes。預設使用者和群組以外的 UNIX 使用者和群組需要由外部 LDAP 名稱服務提供。
下表顯示了預設使用者和群組及其對應的數字 ID。 NetApp建議不要在 LDAP 中或重複使用這些數位 ID 的本機用戶端上建立新的使用者或群組。
預設用戶:數字 ID | 預設群組:數字 ID |
---|---|
|
|
|
使用 NFSv4.1 時,root 使用者在 NFS 用戶端上執行目錄清單指令時可能會顯示為 nobody。這是由於客戶端的ID域映射配置造成的。請參閱名為NFSv4.1 和 nobody 使用者/群組有關此問題及其解決方法的詳細資訊。 |
根用戶
在 Linux 中,root 帳號可以存取基於 Linux 的檔案系統中所有指令、檔案和資料夾。由於此帳戶的強大功能,安全最佳實踐通常要求以某種方式停用或限制根用戶。在 NFS 匯出中,可以透過匯出策略和規則以及稱為 root squash 的概念在Google Cloud NetApp Volumes中控制 root 使用者對檔案和資料夾的權限。
Root 壓縮確保存取 NFS 掛載的 root 使用者被壓縮為匿名數位使用者 65534(請參閱“匿名用戶 "),目前僅在使用NetApp Volumes-Performance 時可用,方法是在建立匯出策略規則期間選擇關閉 root 存取權。如果 root 用戶被壓縮為匿名用戶,則它不再具有運行 chown 或 "setuid/setgid 指令(黏滯位)"在 NFS 掛載中的檔案或資料夾上,以及由 root 使用者建立的檔案或資料夾顯示匿名 UID 作為擁有者/群組。此外,root 使用者無法修改 NFSv4 ACL。但是,root 使用者仍然可以存取 chmod 並刪除其沒有明確權限的檔案。如果要限制對 root 使用者的檔案和資料夾權限的訪問,請考慮使用具有 NTFS ACL 的捲,建立名為 `root`並將所需的權限套用到檔案或資料夾。
匿名用戶
匿名 (anon) 使用者 ID 指定對應到沒有有效 NFS 憑證的用戶端請求的 UNIX 使用者 ID 或使用者名稱。當使用 root 壓縮時,這可以包括 root 使用者。 Google Cloud NetApp Volumes的匿名使用者是 65534。
此 UID 通常與使用者名稱相關聯 nobody`或者 `nfsnobody`在 Linux 環境中。 Google Cloud NetApp Volumes也使用 65534 作為本機 UNIX 使用者 `pcuser
(請參閱“預設本機 UNIX 使用者和群組 "),當在 LDAP 中找不到有效符合的 UNIX 使用者時,它也是 Windows 到 UNIX 名稱對應的預設後備使用者。
由於 Linux 和Google Cloud NetApp Volumes中 UID 65534 的使用者名稱有差異,因此使用 NFSv4.1 時對應到 65534 的使用者的名稱字串可能不符。因此,你可能會看到 `nobody`作為某些文件和資料夾的使用者。請參閱“NFSv4.1 和 nobody 使用者/群組 「以獲取有關此問題及其解決方法的資訊。
存取控制/導出
NFS 掛載的初始導出/共享存取透過導出策略中包含的基於主機的導出策略規則進行控制。定義主機 IP、主機名稱、子網路、網路群組或網域以允許存取掛載 NFS 共用以及允許對主機的存取等級。匯出策略規則設定選項取決於Google Cloud NetApp Volumes等級。
對於NetApp Volumes-SW,以下選項可用於匯出策略配置:
-
*客戶匹配。 *以逗號分隔的 IP 位址清單、以逗號分隔的主機名稱、子網路、網路群組、網域名稱清單。
-
*RO/RW 存取規則。 *選擇讀取/寫入或唯讀來控制導出的存取等級。 NetApp NetApp -Performance 提供以下選項:
-
*客戶匹配。 *以逗號分隔的 IP 位址清單、以逗號分隔的主機名稱、子網路、網路群組、網域名稱清單。
-
*RO/RW 存取規則。 *選擇讀取/寫入或唯讀來控制導出的存取等級。
-
*Root 存取權限(開/關)。 *配置根壁球(請參閱“根用戶 」以了解詳情)。
-
*協定類型。 *這會將對 NFS 掛載的存取限製到特定的協定版本。當為磁碟區同時指定 NFSv3 和 NFSv4.1 時,請將兩者留空或選取兩個方塊。
-
*Kerberos 安全性等級(選擇「啟用 Kerberos」時)。 *提供 krb5、krb5i 和/或 krb5p 選項以進行唯讀或讀寫存取。
更改所有權(chown)和更改組(chgrp)
Google Cloud NetApp Volumes上的 NFS 僅允許 root 使用者對檔案和資料夾執行 chown/chgrp。其他用戶看到 `Operation not permitted`錯誤——即使是他們自己的文件。如果你使用根南瓜(如“根用戶 "),root 被壓縮為非 root 用戶,不允許存取 chown 和 chgrp。目前, Google Cloud NetApp Volumes中沒有允許非 root 使用者使用 chown 和 chgrp 的解決方法。如果需要變更所有權,請考慮使用雙協定磁碟區並將安全樣式設定為 NTFS 以從 Windows 端控制權限。
權限管理
Google Cloud NetApp Volumes支援模式位元(例如 rwx 的 644、777 等)和 NFSv4.1 ACL,以控制使用 UNIX 安全樣式的磁碟區的 NFS 用戶端權限。這些使用標準權限管理(例如 chmod、chown 或 nfs4_setfacl)並可與任何支援它們的 Linux 用戶端一起使用。
此外,當使用設定為 NTFS 的雙協定磁碟區時,NFS 用戶端可以利用Google Cloud NetApp Volumes名稱對應到 Windows 用戶,然後用於解析 NTFS 權限。這需要與Google Cloud NetApp Volumes建立 LDAP 連線以提供數位 ID 到使用者名稱的轉換,因為Google Cloud NetApp Volumes需要有效的 UNIX 使用者名稱才能正確對應到 Windows 使用者名稱。
為 NFSv3 提供細粒度的 ACL
模式位元權限在語義上僅涵蓋擁有者、群組和其他所有人 - 這意味著基本 NFSv3 沒有細粒度的使用者存取控制。 Google Cloud NetApp Volumes不支援 POSIX ACL 和擴充屬性(例如 chattr),因此細粒度 ACL 僅在以下使用 NFSv3 的場景中可用:
-
具有有效 UNIX 到 Windows 使用者對應的 NTFS 安全樣式磁碟區(需要 CIFS 伺服器)。
-
使用安裝 NFSv4.1 的管理用戶端套用 NFSv4.1 ACL 來套用 ACL。
兩種方法都需要 LDAP 連線來進行 UNIX 身分識別管理,並填入有效的 UNIX 使用者和群組資訊(請參閱"LDAP") 並且僅適用於NetApp Volumes-Performance 實例。若要將 NTFS 安全樣式磁碟區與 NFS 一起使用,您必須使用雙協定(SMB 和 NFSv3)或雙協定(SMB 和 NFSv4.1),即使沒有建立 SMB 連線。若要將 NFSv4.1 ACL 與 NFSv3 掛載一起使用,您必須選擇 `Both (NFSv3/NFSv4.1)`作為協定類型。
常規 UNIX 模式位元不提供與 NTFS 或 NFSv4.x ACL 相同的權限粒度。下表比較了 NFSv3 模式位元和 NFSv4.1 ACL 之間的權限粒度。有關 NFSv4.1 ACL 的信息,請參閱 "nfs4_acl - NFSv4 存取控制列表"。
NFSv3 模式位 | NFSv4.1 ACL |
---|---|
|
存取控制條目 (ACE) 類型(允許/拒絕/審核)* 繼承標誌* 目錄繼承* 檔案繼承* 不傳播繼承* 僅繼承 ACL * 讀取資料(檔案)/列出目錄(目錄) * 寫入資料(檔案)/建立檔案(目錄) * 附加資料(檔案)/建立子目錄(目錄) * 執行(檔案)/變更目錄(目錄) * 刪除 * 刪除子項目 * 讀取屬性權限 *寫入屬性 * 讀取命名屬性 * 寫入屬性 * 刪除 * 刪除子項目 * 讀取屬性權限 *寫入屬性 * 讀取命名屬性 * 寫入屬性 * 命名屬性 * |
最後,根據 RPC 封包限制,NFS 群組成員資格(在 NFSv3 和 NFSV4.x 中)對於 AUTH_SYS 的預設最大值限制為 16。 NFS Kerberos 提供最多 32 個群組,NFSv4 ACL 透過細粒度的使用者和群組 ACL(每個 ACE 最多 1024 個條目)消除了限制。
此外, Google Cloud NetApp Volumes也提供擴充組支持,將最大支援組數擴展至 32 個。這需要與包含有效 UNIX 使用者和群組身分的 LDAP 伺服器建立 LDAP 連線。有關配置此功能的更多信息,請參閱 "建立和管理 NFS 卷"在 Google 文件中。
NFSv3 使用者和群組 ID
NFSv3 使用者和群組 ID 以數字 ID 而非名稱的形式透過網路傳輸。 Google Cloud NetApp Volumes不會透過 NFSv3 對這些數位 ID 進行使用者名稱解析,而 UNIX 安全樣式磁碟區僅使用模式位元。當存在 NFSv4.1 ACL 時,需要進行數字 ID 查找和/或名稱字串查找才能正確解析 ACL - 即使使用 NFSv3。對於 NTFS 安全樣式捲, Google Cloud NetApp Volumes必須將數位 ID 解析為有效的 UNIX 用戶,然後對應到有效的 Windows 用戶以協商存取權限。
NFSv3 使用者和群組 ID 的安全限制
使用 NFSv3,客戶端和伺服器永遠不必確認嘗試使用數位 ID 進行讀取或寫入的使用者是否是有效使用者;它只是隱式地受到信任。只需偽造任何數字 ID,檔案系統就有可能受到破壞。為了防止此類安全漏洞, Google Cloud NetApp Volumes提供了一些選項。
-
為 NFS 實作 Kerberos 強制使用者使用使用者名稱和密碼或金鑰表檔案進行驗證,以取得 Kerberos 票證以允許存取掛載。 Kerberos 適用於NetApp Volumes-Performance 實例,且僅適用於 NFSv4.1。
-
限制匯出政策規則中的主機清單會限制哪些 NFSv3 用戶端可以存取Google Cloud NetApp Volumes區。
-
使用雙協定磁碟區並將 NTFS ACL 套用至磁碟區會強制 NFSv3 用戶端將數字 ID 解析為有效的 UNIX 使用者名,以正確驗證存取掛載。這需要啟用 LDAP 並配置 UNIX 使用者和群組身分。
-
壓縮 root 使用者可以限制 root 使用者對 NFS 掛載造成的損害,但並不能完全消除風險。有關詳細信息,請參閱“根用戶 “
最終,NFS 安全性受限於您所使用的協定版本所提供的功能。 NFSv3 雖然整體上比 NFSv4.1 效能更好,但卻無法提供相同等級的安全性。
NFSv4.1
與 NFSv3 相比,NFSv4.1 提供了更高的安全性和可靠性,原因如下:
-
透過基於租賃的機制整合鎖定
-
有狀態會話
-
所有 NFS 功能均透過單一連接埠 (2049)
-
僅 TCP
-
ID域對映
-
Kerberos 整合(NFSv3 可以使用 Kerberos,但僅限於 NFS,不適用於 NLM 等輔助協定)
NFSv4.1 依賴項
由於 NFSv4.1 中增加了安全功能,因此涉及一些使用 NFSv3 時不需要的外部相依性(類似於 SMB 需要 Active Directory 等相依性)。
NFSv4.1 ACL
Google Cloud NetApp Volumes提供對 NFSv4.x ACL 的支持,與普通 POSIX 樣式權限相比,它具有明顯的優勢,例如:
-
精細控制使用者對文件和目錄的訪問
-
更好的 NFS 安全性
-
改進了與 CIFS/SMB 的互通性
-
取消了使用 AUTH_SYS 安全性的 NFS 每個使用者 16 個群組的限制
-
ACL 繞過了群組 ID (GID) 解析的需要,從而有效地消除了 GID 限制。 NFSv4.1 ACL 由 NFS 用戶端控制,而不是由Google Cloud NetApp Volumes控制。若要使用 NFSv4.1 ACL,請確保您的用戶端的軟體版本支援它們並且安裝了正確的 NFS 實用程式。
NFSv4.1 ACL 與 SMB 用戶端之間的相容性
NFSv4 ACL 與 Windows 檔案級 ACL(NTFS ACL)不同,但具有類似的功能。但是,在多協定 NAS 環境中,如果存在 NFSv4.1 ACL 並且您使用雙協定存取(同一資料集上的 NFS 和 SMB),則使用 SMB2.0 及更高版本的用戶端將無法從 Windows 安全性標籤檢視或管理 ACL。
NFSv4.1 ACL 的工作原理
為供參考,定義以下名詞:
-
存取控制清單 (ACL)。權限條目清單。
-
門禁入口 (ACE)。清單中的權限條目。
當用戶端在 SETATTR 作業期間在檔案上設定 NFSv4.1 ACL 時, Google Cloud NetApp Volumes會在物件上設定該 ACL,取代任何現有的 ACL。如果檔案上沒有 ACL,則檔案的模式權限將根據 OWNER@、GROUP@ 和 EVERYONE@ 計算。如果文件上存在任何現有的 SUID/SGID/STICKY 位,則它們不受影響。
當客戶端在 GETATTR 作業過程中取得檔案上的 NFSv4.1 ACL 時, Google Cloud NetApp Volumes會讀取與該物件關聯的 NFSv4.1 ACL,建立 ACE 列表,並將該列表傳回給客戶端。如果檔案具有 NT ACL 或模式位,則由模式位建構 ACL 並傳回給用戶端。
如果 ACL 中存在 DENY ACE,則拒絕存取;如果存在 ALLOW ACE,則允許存取。但是,如果 ACL 中不存在任何 ACE,存取也會被拒絕。
安全描述符由安全性 ACL (SACL) 和自由 ACL (DACL) 組成。 NFSv4.1與CIFS/SMB互通時,DACL與NFSv4、CIFS是一一映射的。 DACL 由 ALLOW ACE 和 DENY ACE 組成。
如果一個基本的 `chmod`在設定了 NFSv4.1 ACL 的檔案或資料夾上執行,現有使用者和群組 ACL 將被保留,但預設的 OWNER@、GROUP@、EVERYONE@ ACL 將被修改。
使用 NFSv4.1 ACL 的客戶端可以設定和檢視系統上檔案和目錄的 ACL。當在具有 ACL 的目錄中建立新檔案或子目錄時,該物件將繼承 ACL 中所有已使用適當標記的 ACE "繼承標誌" 。
如果檔案或目錄具有 NFSv4.1 ACL,則無論使用哪種協定存取該檔案或目錄,都會使用該 ACL 來控制存取。
只要 ACE 標有正確的繼承標誌,檔案和目錄就會從父目錄上的 NFSv4 ACL 繼承 ACE(可能經過適當的修改)。
當根據 NFSv4 請求建立檔案或目錄時,產生的檔案或目錄上的 ACL 取決於檔案建立請求是否包含 ACL 或僅包含標準 UNIX 檔案存取權限。 ACL 也取決於父目錄是否有 ACL。
-
如果請求包含 ACL,則使用該 ACL。
-
如果請求僅包含標準 UNIX 檔案存取權限,且父目錄沒有 ACL,則使用用戶端檔案模式設定標準 UNIX 檔案存取權限。
-
如果請求僅包含標準 UNIX 檔案存取權限,且父目錄具有不可繼承的 ACL,則會在新物件上設定基於傳遞到請求中的模式位元的預設 ACL。
-
如果請求僅包含標準 UNIX 檔案存取權限,但父目錄具有 ACL,則只要 ACE 已使用適當的繼承標誌進行標記,父目錄的 ACL 中的 ACE 就會被新檔案或目錄繼承。
ACE 權限
NFSv4.1 ACL 權限使用一系列大寫和小寫字母值(例如 rxtncy
) 來控制存取。有關這些字母值的更多信息,請參閱 "如何使用 NFSv4 ACL"。
具有 umask 和 ACL 繼承的 NFSv4.1 ACL 行為
"NFSv4 ACL 提供 ACL 繼承功能" 。ACL 繼承意味著在設定了 NFSv4.1 ACL 的物件下建立的檔案或資料夾可以根據 "ACL 繼承標誌"。
"烏馬斯克"用於控制無需管理員互動即可在目錄中建立檔案和資料夾的權限等級。預設情況下, Google Cloud NetApp Volumes允許 umask 覆寫繼承的 ACL,這是根據 "RFC 5661"。
ACL 格式
NFSv4.1 ACL 具有特定的格式。以下範例是文件上的 ACE 設定:
A::ldapuser@domain.netapp.com:rwatTnNcCy
上述範例遵循以下 ACL 格式準則:
type:flags:principal:permissions
一種 `A`意思是「允許」。在這種情況下,不會設定繼承標誌,因為主體不是一個群組並且不包括繼承。此外,由於 ACE 不是 AUDIT 條目,因此無需設定審計標誌。有關 NFSv4.1 ACL 的更多信息,請參閱 "http://linux.die.net/man/5/nfs4_acl"。
如果 NFSv4.1 ACL 設定不正確(或用戶端和伺服器無法解析名稱字串),ACL 可能不會如預期執行,或者 ACL 變更可能無法套用並引發錯誤。
範例錯誤包括:
Failed setxattr operation: Invalid argument Scanning ACE string 'A:: user@rwaDxtTnNcCy' failed.
明確拒絕
NFSv4.1 權限可以包括 OWNER、GROUP 和 EVERYONE 的明確 DENY 屬性。這是因為 NFSv4.1 ACL 是預設拒絕的,這表示如果 ACE 未明確授予 ACL,則會被拒絕。明確的 DENY 屬性將覆蓋任何 ACCESS ACE,無論是否明確。
DENY ACE 的屬性標籤為 D
。
在下面的範例中,GROUP@ 被允許所有讀取和執行權限,但被拒絕所有寫入存取權限。
sh-4.1$ nfs4_getfacl /mixed A::ldapuser@domain.netapp.com:ratTnNcCy A::OWNER@:rwaDxtTnNcCy D::OWNER@: A:g:GROUP@:rxtncy D:g:GROUP@:waDTC A::EVERYONE@:rxtncy D::EVERYONE@:waDTC
應盡可能避免使用 DENY ACE,因為它們可能令人困惑且複雜;未明確定義的 ALLOW ACL 將被隱式拒絕。當設定了 DENY ACE 時,使用者在期望獲得存取權限時可能會被拒絕存取。
上述一組 ACE 相當於模式位元中的 755,這表示:
-
所有者擁有充分的權利。
-
群組具有唯讀權限。
-
其他人只讀。
但是,即使將權限調整為 775,由於 EVERYONE 上明確設定了 DENY,存取也可能會被拒絕。
NFSv4.1 ID 域對映依賴關係
NFSv4.1 利用 ID 網域對映邏輯作為安全層,幫助驗證嘗試存取 NFSv4.1 掛載的使用者確實是他們所聲稱的使用者。在這些情況下,來自 NFSv4.1 用戶端的使用者名稱和群組名稱會附加一個名稱字串並將其傳送到Google Cloud NetApp Volumes實例。如果使用者名稱/群組名稱和 ID 字串組合不匹配,則該使用者和/或群組將被壓縮為 `/etc/idmapd.conf`客戶端上的文件。
此 ID 字串是遵守正確權限的必要條件,尤其是在使用 NFSv4.1 ACL 和/或 Kerberos 時。因此,需要名稱服務伺服器相依性(例如 LDAP 伺服器)來確保客戶端和Google Cloud NetApp Volumes之間的一致性,以便正確解析使用者和群組名稱身分。
Google Cloud NetApp Volumes使用靜態預設 ID 網域值 defaultv4iddomain.com
。 NFS 用戶端預設使用 DNS 網域名稱作為其 ID 網域名稱設置,但您可以在 /etc/idmapd.conf
。
如果在Google Cloud NetApp Volumes中啟用了 LDAP,則Google Cloud NetApp Volumes會自動將 NFS ID 網域變更為 DNS 中搜尋網域的配置,且用戶端無需修改,除非它們使用不同的 DNS 網域搜尋名稱。
當Google Cloud NetApp Volumes可以解析本機檔案或 LDAP 中的使用者名稱或群組名稱時,將使用網域字串,而不符合的網域 ID 將被壓縮為 nobody。如果Google Cloud NetApp Volumes在本機檔案或 LDAP 中找不到使用者名稱或群組名,則使用數字 ID 值,且 NFS 用戶端會正確解析該名稱(這類似於 NFSv3 行為)。
如果不變更客戶端的 NFSv4.1 ID 網域以符合Google Cloud NetApp Volumes磁碟區正在使用的網域,您會看到下列行為:
-
Google Cloud NetApp Volumes中具有本機條目的 UNIX 使用者和群組(例如 root,如本機 UNIX 使用者和群組中所定義)被壓縮為 nobody 值。
-
如果 NFS 用戶端和Google Cloud NetApp Volumes Google Cloud NetApp Volumes配置為使用 LDAP)將被壓縮為 nobody。
-
沒有本機條目或 LDAP 條目的 UNIX 使用者和群組使用數字 ID 值並解析為 NFS 用戶端上指定的名稱。如果用戶端上不存在名稱,則僅顯示數字 ID。
下面顯示了上述場景的結果:
# ls -la /mnt/home/prof1/nfs4/ total 8 drwxr-xr-x 2 nobody nobody 4096 Feb 3 12:07 . drwxrwxrwx 7 root root 4096 Feb 3 12:06 .. -rw-r--r-- 1 9835 9835 0 Feb 3 12:07 client-user-no-name -rw-r--r-- 1 nobody nobody 0 Feb 3 12:07 ldap-user-file -rw-r--r-- 1 nobody nobody 0 Feb 3 12:06 root-user-file
當客戶端和伺服器 ID 網域相符時,相同的檔案清單如下所示:
# ls -la total 8 drwxr-xr-x 2 root root 4096 Feb 3 12:07 . drwxrwxrwx 7 root root 4096 Feb 3 12:06 .. -rw-r--r-- 1 9835 9835 0 Feb 3 12:07 client-user-no-name -rw-r--r-- 1 apache apache-group 0 Feb 3 12:07 ldap-user-file -rw-r--r-- 1 root root 0 Feb 3 12:06 root-user-file
有關此問題及其解決方法的更多信息,請參閱“NFSv4.1 和 nobody 使用者/群組 “
Kerberos 依賴項
如果您打算將 Kerberos 與 NFS 結合使用,則必須具備以下Google Cloud NetApp Volumes:
-
Kerberos 分發中心服務 (KDC) 的 Active Directory 網域
-
具有使用者和群組屬性的 Active Directory 網域,其中填充了用於 LDAP 功能的 UNIX 資訊( Google Cloud NetApp Volumes中的 NFS Kerberos 需要使用者 SPN 到 UNIX 使用者對應才能正常運作。)
-
Google Cloud NetApp Volumes實例上啟用了 LDAP
-
DNS 服務的 Active Directory 網域
NFSv4.1 和 nobody 使用者/群組
NFSv4.1 配置中最常見的問題之一是當檔案或資料夾顯示在清單中時使用 ls`歸 `user:group`組合 `nobody:nobody
。
例如:
sh-4.2$ ls -la | grep prof1-file -rw-r--r-- 1 nobody nobody 0 Apr 24 13:25 prof1-file
數位 ID 是 99
。
sh-4.2$ ls -lan | grep prof1-file -rw-r--r-- 1 99 99 0 Apr 24 13:25 prof1-file
在某些情況下,文件可能會顯示正確的所有者,但 `nobody`作為團體。
sh-4.2$ ls -la | grep newfile1 -rw-r--r-- 1 prof1 nobody 0 Oct 9 2019 newfile1
誰是沒人?
這 `nobody`NFSv4.1 中的使用者與 `nfsnobody`用戶。您可以透過執行以下命令來查看 NFS 用戶端如何查看每個用戶 `id`命令:
# id nobody uid=99(nobody) gid=99(nobody) groups=99(nobody) # id nfsnobody uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)
使用 NFSv4.1, `nobody`用戶是 `idmapd.conf`文件,可以定義為您想要使用的任何使用者。
# cat /etc/idmapd.conf | grep nobody #Nobody-User = nobody #Nobody-Group = nobody
為什麼會發生這種情況?
因為透過名稱字串映射實現的安全性是 NFSv4.1 操作的關鍵原則,所以當名稱字串無法正確匹配時,預設行為是將該使用者壓縮為通常無法存取使用者和群組所擁有的檔案和資料夾的使用者。
當你看到 `nobody`對於檔案清單中的使用者和/或群組,這通常意味著 NFSv4.1 中的某些內容配置錯誤。這裡需要區分大小寫。
例如,如果 user1@CVSDEMO.LOCAL (uid 1234, gid 1234) 正在存取匯出, Google Cloud NetApp Volumes必須能夠找到 user1@CVSDEMO.LOCAL (uid 1234, gid 1234)。如果Google Cloud NetApp Volumes中的使用者是 USER1@CVSDEMO.LOCAL,則不會相符(大寫 USER1 與小寫 user1)。在許多情況下,您可以在客戶端的訊息檔案中看到以下內容:
May 19 13:14:29 centos7 nfsidmap[17481]: nss_getpwnam: name 'root@defaultv4iddomain.com' does not map into domain 'CVSDEMO.LOCAL' May 19 13:15:05 centos7 nfsidmap[17534]: nss_getpwnam: name 'nobody' does not map into domain 'CVSDEMO.LOCAL'
客戶端和伺服器必須都同意用戶確實是他們所聲稱的用戶,因此您必須檢查以下內容以確保客戶端看到的用戶與Google Cloud NetApp Volumes看到的用戶具有相同的資訊。
-
NFSv4.x ID 域。客戶: `idmapd.conf`文件; Google Cloud NetApp Volumes使用 `defaultv4iddomain.com`並且無法手動更改。如果將 LDAP 與 NFSv4.1 一起使用, Google Cloud NetApp Volumes會將 ID 網域變更為 DNS 搜尋網域正在使用的網域,該網域與 AD 網域相同。
-
*用戶名和數字 ID。 *這確定了客戶端在哪裡尋找用戶名,並利用名稱服務交換器來設定客戶端: `nsswitch.conf`和/或本機密碼和群組檔案; Google Cloud NetApp Volumes不允許對此進行修改,但在啟用時會自動將 LDAP 新增至設定。
-
*組名和數字 ID。 *這確定了客戶端在哪裡尋找群組名,並利用名稱服務交換器來設定客戶端: `nsswitch.conf`和/或本機密碼和群組檔案; Google Cloud NetApp Volumes不允許對此進行修改,但在啟用時會自動將 LDAP 新增至設定。
在幾乎所有情況下,如果你看到 `nobody`在客戶端的使用者和群組清單中,問題是Google Cloud NetApp Volumes和 NFS 用戶端之間的使用者或群組名稱 ID 轉換。為避免這種情況,請使用 LDAP 解析客戶端和Google Cloud NetApp Volumes之間的使用者和群組資訊。
在客戶端上查看 NFSv4.1 的名稱 ID 字串
如果您使用的是 NFSv4.1,則在 NFS 操作期間會發生名稱字串映射,如前所述。
除了使用 `/var/log/messages`要查找 NFSv4 ID 的問題,您可以使用 "nfsidmap -l"在 NFS 用戶端上執行命令以查看哪些使用者名稱已正確對應到 NFSv4 網域。
例如,這是客戶端和Google Cloud NetApp Volumes可以找到的使用者存取 NFSv4.x 掛載後命令的輸出:
# nfsidmap -l 4 .id_resolver keys found: gid:daemon@CVSDEMO.LOCAL uid:nfs4@CVSDEMO.LOCAL gid:root@CVSDEMO.LOCAL uid:root@CVSDEMO.LOCAL
當使用者沒有正確地對應到 NFSv4.1 ID 網域時(在這種情況下, netapp-user
) 嘗試存取相同的掛載並接觸文件,它們被分配 nobody:nobody
,正如預期的那樣。
# su netapp-user sh-4.2$ id uid=482600012(netapp-user), 2000(secondary) sh-4.2$ cd /mnt/nfs4/ sh-4.2$ touch newfile sh-4.2$ ls -la total 16 drwxrwxrwx 5 root root 4096 Jan 14 17:13 . drwxr-xr-x. 8 root root 81 Jan 14 10:02 .. -rw-r--r-- 1 nobody nobody 0 Jan 14 17:13 newfile drwxrwxrwx 2 root root 4096 Jan 13 13:20 qtree1 drwxrwxrwx 2 root root 4096 Jan 13 13:13 qtree2 drwxr-xr-x 2 nfs4 daemon 4096 Jan 11 14:30 testdir
這 nfsidmap -l`輸出顯示用戶 `pcuser`在顯示幕上,但沒有 `netapp-user
;這是我們的導出策略規則中的匿名用戶(65534
)。
# nfsidmap -l 6 .id_resolver keys found: gid:pcuser@CVSDEMO.LOCAL uid:pcuser@CVSDEMO.LOCAL gid:daemon@CVSDEMO.LOCAL uid:nfs4@CVSDEMO.LOCAL gid:root@CVSDEMO.LOCAL uid:root@CVSDEMO.LOCAL