使用 gsscred 表

當一個伺服器試著識別一位 SEAM 使用者的身份時，NFS 伺服器便會使用 gsscred 表。NFS 服務會利用 UNIX 識別碼來識別使用者，這些識別碼不是使用者主管或證書的一部份。gsscred 表可以提供從 UNIX UID（從密碼檔案）至主管名稱的對映。在您公開 KDC 資料庫之後就必須建立與管理此表格。

收到一個客戶端的要求時，NFS 服務會試著將主管名稱對映至一個 UNIX 識別碼。如果對映失敗，它就會參考 gsscred 表。一個 root/hostname 主管會自動以 kerberos_v5 機制來對映至 UID 0，此時就不會參考到 gsscred 表。這表示您無法利用 gsscred 表來特別重新對映 root。

選擇何種機制，為gsscred表

要為 gsscred 表選取正確的機制，有下列幾項考慮因素﹕

• 您是否想要改善查詢時間？

• 您是否想要增加資料的存取安全？

• 您是否需要很快地建構檔案？

下列為所有可供選擇的的後端機制，以及這些機制的優點說明。

檔案

gsscred 表儲存在一個檔案系統中。這個無法分享的本機檔案系統可以提供最安全的後端支援，因為在表格建立之後就沒有透過網路來進行任何的傳輸。本版的檔案建構時間最短。

xfn_files

gsscred 表儲存在 /var/fn 檔案系統中。您可以決定是否要分享此檔案系統。所有的 xfn 檔案都需要花很長時間來建構。

xfn_nis

gsscred 表儲存在 NIS 名稱空間。此檔案系統上的查詢並不安全。所有的 xfn 檔案都需要花很長時間來建構。

xfn_nisplus

gsscred 表儲存在 NIS+ 名稱空間。此檔案系統的查詢並不安全。所有的 xfn 檔案都需要花很長時間來建構。

xfn

gsscred 表儲存在 xfn 的預設系統中。所有的 xfn 檔案都需要花很長時間來建構。

檔案後端機制的初始查詢會很慢，而其他機制的初始查詢可以利用一個名稱服務來加快。就所有的機制而言，只要快取過資料之後，其擷取時間就會大同小異。