gsscred テーブルは、NFS サーバーが SEAM ユーザーを識別するときに使用します。NFS サービスは UNIX ID を使用してユーザーを識別しますが、この ID はユーザープリンシパルや資格の一部ではありません。gsscred テーブルは、パスワードファイルから得られる UNIX ID とプリンシパル名を対応付けるテーブルです。このテーブルは、KDC データベースにデータを入力したあとに作成および開始する必要があります。
クライアントの要求が到着すると、NFS サービスはプリンシパル名を UNIX ID に対応づけようとします。そして、この変換に失敗すると、gsscred テーブルを使用します。kerberos_v5 メカニズムでは、root/hostname プリンシパルは自動的に UID 0 に対応付けられるため、gsscred テーブルは使用されません。したがって、gsscred テーブルを使用して root を特別な UID に対応づけることはできません。
gsscred テーブルに対しどのメカニズムを選択するかは、次の要素で決まります。
検索時間の短縮に関心があるか
データアクセスのセキュリティ向上に関心があるか
ファイルを短時間で作成する必要があるか
次に、選択可能なバックエンドメカニズムとその利点を説明します。
gsscred テーブルはファイルシステムに格納されます。テーブルが作成された後はネットワークを介した伝送は行われないため、共有されないローカルファイルシステムが最も安全なバックエンドです。このタイプのファイルが最も短時間で作成されます。
gsscred テーブルは /var/fn ファイルシステムに格納されます。このファイルシステムは共有されていても、されていなくてもかまいません。xfn ファイルはどれも作成に長い時間がかかります。
gsscred テーブルは NIS 名前空間に格納されます。このファイルシステムの検索は安全ではありません。xfn ファイルはどれも作成に長い時間がかかります。
gsscred テーブルは NIS+ 名前空間に格納されます。このファイルシステムの検索は安全ではありません。xfn ファイルはどれも作成に長時間かかります。
gsscred テーブルは xfn のデフォルトシステムに格納されます。xfn ファイルはどれも作成に長時間かかります。
files バックエンドメカニズムでは、最初の検索が遅いことがあります。他のメカニズムでは、最初の検索はネームサービスを使用してこれより速く行われます。どのメカニズムでも、データがキャッシュされたあとの検索時間はほぼ同じです。