使用gsscred 表

当一个 NFS 服务器试图识别一个 SEAM 用户时，就使用 gsscred 表。 NFS 服务使用 UNIX ID 来识别用户，而这些 ID 并非用户授权对象或资格的一部分。 gsscred 表提供了一个从 UNIX UID (从口令文件) 到授权对象名称的映射。在 KDC 数据库被植入数据之后，必须创建该表并进行管理。

当一个客户机请求来到时， NFS 服务就试图将授权对象名称映射到一个 UNIX ID。如果映射失败，就问询 gsscred 表。借助 Kerberos_v5 机制，一个 root/hostname授权对象会自动被映射到 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 文件建立起来要花费较长的时间。

对于 文件 后端机制，初始检索可能会很慢。对于其它的机制，使用一个名称服务时，初始检索可能会较快。对于所有机制，在数据得到高速缓存之后，检索时间应当大致相同。