AUTH_SYS

これは AUTH_UNIX として知られる、以前に説明した認証 flavor と同じです。リモートプロシージャを呼び出す側では、従来の UNIX のプロセス許可認証を使用して自分自身を証明する場合があります。そのような RPC 呼び出しメッセージでは、opaque_auth の flavor は AUTH_SYS となります。body には、次に示す構造体が符号化されます。

struct auth_sysparms {
  	unsigned int  stamp;
  	string machinename<255>;
  	uid_t uid;
  	gid_t gid;
  	gid_t gids<10>;
 };

stamp

呼び出し側のマシンで生成できる任意の ID

machinename

呼び出し側マシンの名前

uid

呼び出し側の実効ユーザー ID

gid

呼び出し側の実行グループ ID

gids

呼び出し側がメンバーであるグループの可変長配列

資格に伴うベリファイアの flavor は AUTH_NONE でなければなりません。

AUTH_SHORT ベリファイア

AUTH_SYS タイプの認証を使用するときは、サーバーからの応答メッセージに入っている応答ベリファイアの flavor は AUTH_NONE か AUTH_SHORT のどちらかです。

AUTH_SHORT の場合、応答ベリファイアの文字列には short_hand_verf 構造体が符号化されています。この隠された構造体を、元の AUTH_SYS 資格の代わりにサーバーに渡すことができます。

サーバー側では、隠された short_hand_verf 構造体を呼び出し側の元の資格にマップするキャッシュを保存します。AUTH_SHORT タイプの応答ベリファイアがこれらの構造体を返します。呼び出し側は、新たな資格を使用してネットワークの帯域幅とサーバーの CPU サイクルを保存できます。

サーバー側では、隠された short_hand_verf 構造体をいつでもフラッシュできます。フラッシュが発生した場合、リモートプロシージャコールメッセージは認証エラーにより拒否されます。エラー原因は AUTH_REJECTEDCRED になります。この場合、次の図のように呼び出し側では、AUTH_SYS タイプの元の資格を試すこともできます。

図 B–1 認証プロセスマップ