コールバック

これ以外に cookie が使用される場所は、コールバックです。サーバーは、rpc_gss_set_callback() 関数を使用することにより、ユーザー定義のコールバックを指定して、コンテキストが最初に使用された時を認知できます。コールバックは、コンテキストが指定されたプログラムとバージョン用に確立されたあとに、そのコンテキストがデータ交換に最初に使用された時に呼び出されます。

ユーザー定義のコールバックルーチンは、以下のような形式になります。

bool_t callback (struct svc_req *req,  gss_cred_id_t deleg,
gss_ctx_id_t  gss_context rpc_gss_lock_t *
lock void ** cookie);

2 番めと 3 番めの引数 deleg と gss_context は、GSS-API データタイプで、現在はまだ公開されていません。詳細については、『GSS-API のプログラミング』 を参照してください。 deleg は委譲されたピアを識別する情報になり、一方 gss_context は GSS-API コンテキストへのポインタになります。プログラムが GSS-API 処理をこのコンテキスト上で実行する必要がある場合、つまり受信条件のテストをする場合に、このポインタが必要となります。 cookie 引数については、すでに説明しました。

lock 引数は、以下のように rpc_gss_lock_t 構造体へのポインタです。

 
typedef struct {
 	bool_t 						locked;
		rpc_gss_rawcred_t		*raw_cred;
} rpc_gss_lock_t;

このパラメータを使用すると、サーバーはセッションに対し強制的に特定の QOP とサービスを実行できます。例 5–14 に記載したように、QOP とサービスは、rpc_gss_rawcred_t 構造体内で検出できます。サーバーは、サービスと QOP の値を変更する必要はありません。ユーザー定義のコールバックが呼び出されると、locked は FALSE に設定されます。サーバーが、locked を TRUE に設定すると、QOP とサービスの値が、rpc_gss_rawcred_t 構造体内の値と一致する要求だけが受理されます。

詳細は、rpc_gss_set_callback(3NSL) のマニュアルページを参照してください。