核心 RPC 伺服器的 rpcsec_gss 支援

本文件提供了用於在核心 RPC 伺服器（例如 NFS 伺服器和 NFS 客戶端的 NFSv4.0 回撥伺服器）中實現 RPCGSS 身份驗證的標準和協議的參考。（但請注意，NFSv4.1 及更高版本不需要客戶端充當伺服器進行身份驗證。）

RPCGSS 在一些 IETF 文件中進行了規定

我們目前沒有實現第三個版本

背景

RPCGSS 身份驗證方法描述了一種為 NFS 執行 GSSAPI 身份驗證的方法。雖然 GSSAPI 本身完全與機制無關，但在許多情況下，只有 KRB5 機制受到 NFS 實現的支援。

Linux 核心目前僅支援 KRB5 機制，並且依賴於 KRB5 特定的 GSSAPI 擴充套件。

GSSAPI 是一個複雜的庫，在核心中完全實現它是沒有必要的。 但是，GSSAPI 操作在根本上可以分為兩部分

  • 初始上下文建立

  • 完整性/隱私保護（簽名和加密單個數據包）

前者更復雜且與策略無關，但對效能不太敏感。 後者更簡單，需要非常快。

因此，我們在核心中執行每個資料包的完整性和隱私保護，但將初始上下文建立留給使用者空間。我們需要 upcall 來請求使用者空間執行上下文建立。

NFS 伺服器舊版 Upcall 機制

經典的 upcall 機制使用自定義的基於文字的 upcall 機制與由 nfs-utils 軟體包提供的自定義守護程式 rpc.svcgssd 通訊。

這種 upcall 機制有兩個限制

  1. 它可以處理不超過 2KiB 的令牌

在某些 Kerberos 部署中，由於附加到 Kerberos 票證的各種授權擴充套件，GSSAPI 令牌可能非常大，高達 64KiB 以上，這些授權擴充套件需要透過 GSS 層傳送才能執行上下文建立。

B) 由於可以傳送回核心的緩衝區大小的限制（4KiB），它無法正確處理使用者所屬組超過數千個（核心中當前的硬性限制是 65K 個組）的憑據。

NFS 伺服器新 RPC Upcall 機制

較新的 upcall 機制使用基於 unix 套接字的 RPC 與名為 gss-proxy 的守護程式通訊，該守護程式由名為 Gssproxy 的使用者空間程式實現。

gss_proxy RPC 協議目前在此處記錄：此處.

此 upcall 機制使用核心 rpc 客戶端並透過常規 unix 套接字連線到 gssproxy 使用者空間程式。 gssproxy 協議不存在舊版協議的大小限制。

協商 Upcall 機制

為了提供向後相容性，核心預設使用舊版機制。 要切換到新機制，gss-proxy 必須繫結到 /var/run/gssproxy.sock，然後將“1”寫入 /proc/net/rpc/use-gss-proxy。 如果 gss-proxy 死亡，它必須重複這兩個步驟。

一旦選擇了 upcall 機制，就無法更改它。 為了防止鎖定到舊版機制，必須在啟動 nfsd 之前執行上述步驟。 啟動 nfsd 的人可以透過從 /proc/net/rpc/use-gss-proxy 讀取並檢查它是否包含“1”來保證這一點——讀取操作將阻塞，直到 gss-proxy 將其寫入檔案為止。