RPC プログラミングの高度なテクニック
この節では、RPC の下位レベルインタフェースを使用するさまざまな開発テクニックを説明します。この章で説明する項目を次に示します。
-
サーバ上の poll() - サーバ上で svc_run() が呼び出せない場合に、サーバから直接ディスパッチャを呼び出す方法
-
ブロードキャスト RPC - ブロードキャストの使用方法
-
バッチ処理 - 一連の呼び出しをバッチ処理にして、パフォーマンスを向上する方法
-
認証 - 今回のリリースで使用される認証方法
-
ポートモニタの使用 - ポートモニタ inetd と listener のインタフェース
-
サーバのバージョン - 複数のプログラムバージョンのサービス方法
サーバ側の poll()
この節で説明する内容は、(デフォルトで) シングルスレッドのモードで RPC を実行する場合にだけ適用されます。
RPC 要求をサービスしたり、その他のアクティビティを実行したりするプロセスでは、svc_run() を呼び出せない場合があります。他のアクティビティで定期的にデータ構造を更新する場合は、プロセスから svc_run() を呼び出す前に SIGALRM 信号をセットできます。そうすると、シグナルハンドラがデータ構造を処理してから svc_run() に制御を戻します。
プロセスから svc_run() をバイパスして直接ディスパッチャにアクセスするには、svc_getreqset() を呼び出します。待っているプログラムに結合したトランスポート端点のファイル記述子がわかれば、プロセスは自分で poll() を呼び出して、RPC ファイル記述子と自身の記述子の両方で要求を待つことができます。
例 4-20 には svc_run() を示します。svc_pollset は、__rpc_select_to_poll() の呼び出しを通して svc_fdset() から派生した pollfd 構造体の配列です。この配列は、RPC ライブラリルーチンのどれかが呼び出されるたびに変わる可能性があります。そのたびに記述子がオープンされ、クローズされるからです。poll() がいくつかの RPC ファイル記述子への RPC 要求の到着を確認すると、svc_getreq_poll() が呼び出されます。
注 -
関数 __rpc_dtbsize() と __rpc_select_to_poll() は、SVID の一部ではありませんが、libnsl ライブラリで使用できます。Solaris 以外でも実行できるように、これらの関数を作成する方のために、関数の仕様を説明します。
int __rpc_select_to_poll(int fdmax, fd_set *fdset, struct pollfd *pollset)
ビットフラグとして fd_set ポインタとチェックすべきビット数が指定されます。この関数内で、指定された pollfd 配列を RPC が使用するために初期化するようにします。RPC は、入力イベントだけをポーリングします。初期化された pollfd スロット数が返されます。
int __rpc_dtbsize()
この関数は、getrlimit() 関数を呼び出し、新しく作成された記述子にシステムが割り当てる最大値を決定します。結果は、効率化のためにキャッシュされます。
この節のSVIDルーチンについての詳細は、 rpc_svc_calls(3N) および poll(2) のマニュアルページを参照してください。
例 4-20 svc_run( ) と poll( )
void
svc_run()
{
int nfds;
int dtbsize = __rpc_dtbsize();
int i;
struct pollfd svc_pollset[fd_setsize];
for (;;) {
/*
* 要求待ちするサーバ fd があるかどうかをチェック
*/
nfds = __rpc_select_to_poll(dtbsize, &svc_fdset,
svc_pollset);
if (nfds == 0)
break; /* 要求待ちの fd がないので終了 */
switch (i = poll(svc_pollset, nfds, -1)) {
case -1:
/*
* エラーが起こった場合は、poll() ではなく、シグナルハンドラなど
* 外部イベントによるものと考えて、無視して継続する
*/
case 0:
continue;
default:
svc_getreq_poll(svc_pollset, i);
}
}
}
ブロードキャスト RPC
RPC のブロードキャストが要求されると、メッセージはネットワーク上の rpcbind デーモンに送られます。要求されたサービスが登録されている rpcbind デーモンは、その要求をサーバに送ります。ブロードキャスト RPC と通常の RPC 呼び出しとの主な相違点を次に示します。
-
通常の RPC では応答は 1 つですが、ブロードキャスト RPC には複数の応答があります (メッセージに応答するすべてのマシンから応答が返されます)。
-
ブロードキャスト RPC は、UDP のようにブロードキャスト RPC をサポートする非接続型プロトコルでしか使用できません。
-
ブロードキャスト RPC では、正常終了以外の応答は返されません。したがって、ブロードキャスタと遠隔のサービスでバージョンの不一致があれば、サービスからブロードキャスタには何も返されません。
-
ブロードキャスト RPC では、rpcbind で登録されたデータグラムサービスだけがアクセス可能です。サービスアドレスはホストごとに異なりますので、rpc_broadcast() は、rpcbind のネットワークアドレスにメッセージを送信します。
-
ブロードキャスト要求のサイズはローカルネットワークの最大伝送ユニット (MTU:maximum trasfer unit) により制限されます。イーサネットの MTU は 1500 バイトです。
例 4-21 では、rpc_broadcast() の使用方法を示し、引数を説明します。
例 4-21 RPC ブロードキャスト
/*
* コード例 4-21 RPC ブロードキャスト
*/
#include <stdio.h>
#include <rpc/rpc.h>
main(argc, argv)
int argc;
char *argv[];
{
enum clnt_stat rpc_stat;
u_long prognum, vers;
struct rpcent *re;
if(argc != 3) {
fprintf(stderr, "usage : %s RPC_PROG VERSION¥n", argv[0]);
exit(1);
}
if (isdigit( *argv[1]))
prognum = atoi(argv[1]);
else {
re = getrpcbyname(argv[1]);
if (! re) {
fprintf(stderr, "Unknown RPC service %s¥n", argv[1]);
exit(1);
}
prognum = re->r_number;
}
vers = atoi(argv[2]);
rpc_stat = rpc_broadcast(prognum, vers, NULLPROC, xdr_void,
(char *)NULL, xdr_void, (char *)NULL, bcast_proc,
NULL);
if ((rpc_stat != RPC_SUCCESS) && (rpc_stat != RPC_TIMEDOUT)) {
fprintf(stderr, "broadcast failed: %s¥n",
clnt_sperrno(rpc_stat));
exit(1);
}
exit(0);
}
例 4-22 の関数 bcast_proc() では、ブロードキャストに対する応答を収集します。通常は、最初の応答だけを取り出すか、応答をすべて収集します。bcast_proc() は、応答を返したサーバの IP アドレスを表示します。この関数は FALSE を返して応答の収集を続け、RPC クライアントコードはタイムアウトが来るまでブロードキャストを再送信し続けます。
例 4-22 ブロードキャストへの応答の収集
bool_t
bcast_proc(res, t_addr, nconf)
void *res; /* 応答なし */
struct t_bind *t_addr; /* 応答したアドレス */
struct netconfig *nconf;
{
register struct hostent *hp;
char *naddr;
naddr = taddr2naddr(nconf, &taddr->addr);
if (naddr == (char *) NULL) {
fprintf(stderr,"Responded: unknown¥n");
} else {
fprintf(stderr,"Responded: %s¥n", naddr);
free(naddr);
}
return(FALSE);
}
TRUE が返されるとブロードキャストは終了し、rpc_broadcast() は正常終了します。FALSE が返された場合は、次の応答を待ちます。数秒間待ってから、要求が再びブロードキャストされます。応答が返されない場合は、rpc_broadcast() は RPC_TIMEDOUT を返します。
バッチ処理
RPC の設計方針では、クライアントは呼び出しメッセージを送信して、サーバがそれに応答するのを待ちます。すなわち、サーバが要求を処理する間、クライアントは停止していることになります。これは、クライアントが各メッセージへの応答を待つ必要がないときには非効率です。
RPC のバッチ処理を使用すると、クライアントは非同期に処理を進めることができます。RPC メッセージは呼び出しパイプラインに入れてサーバに送られます。バッチ処理では次のことが必要になります。
-
サーバはどのような中間メッセージにも応答しません。
-
呼び出しパイプラインは、信頼性の高いトランスポート (たとえば、TCP) で伝送されなければなりません。
-
呼び出し時に指定する、戻り値に対する XDR ルーチンは NULL でなければなりません。
-
RPC 呼び出しのタイムアウト値はゼロでなければなりません。
サーバはそれぞれの呼び出しに対しては応答しないので、クライアントは、サーバが前の呼び出しを処理している間に平行して次の呼び出しを送信できます。トランスポートは複数の呼び出しメッセージをバッファリングし、システムコール write() で一度にサーバに送信します。こうすることにより、プロセス間通信のオーバヘッドを減らし、一連の呼び出しに要する総時間を短縮します。クライアントは終了前に、パイプラインをフラッシュする呼び出しをバッチにしないで実行します。
例 4-23には、バッチ処理を使用しないクライアント側プログラムを示します。文字配列 buf を走査して文字列を順に取り出し、1 つずつサーバに送信します。
例 4-23 バッチ処理を使用しないクライアントプログラム
#include <stdio.h>
#include <rpc/rpc.h>
#include "windows.h"
main(argc, argv)
int argc;
char **argv;
{
struct timeval total_timeout;
register CLIENT *client;
enum clnt_stat clnt_stat;
char buf[1000], *s = buf;
if ((client = clnt_create( argv[1], WINDOWPROG, WINDOWVERS,
"circuit_v")) == (CLIENT *) NULL) {
clnt_pcreateerror("clnt_create");
exit(1);
}
total_timeout.tv_sec = 20;
total_timeout.tv_usec = 0;
while (scanf( "%s", s ) != EOF) {
if (clnt_call(client, RENDERSTRING, xdr_wrapstring, &s,
xdr_void, (caddr_t) NULL, total_timeout) != RPC_SUCCESS) {
clnt_perror(client, "rpc");
exit(1);
}
}
clnt_destroy( client );
exit(0);
}
例 4-24には、このクライアントプログラムでバッチ処理を使用する場合を示します。各文字列の送信ごとには応答を待たず、サーバからの終了応答だけを待ちます
例 4-24 バッチ処理を使用するクライアントプログラム
#include <stdio.h>
#include <rpc/rpc.h>
#include "windows.h"
main(argc, argv)
int argc;
char **argv;
{
struct timeval total_timeout;
register CLIENT *client;
enum clnt_stat clnt_stat;
char buf[1000], *s = buf;
if ((client = clnt_create( argv[1], WINDOWPROG, WINDOWVERS,
"circuit_v")) == (CLIENT *) NULL) {
clnt_pcreateerror("clnt_create");
exit(1);
}
timerclear(&total_timeout);
while (scanf("%s", s) != EOF)
clnt_call(client, RENDERSTRING_BATCHED, xdr_wrapstring,
&s, xdr_void, (caddr_t) NULL, total_timeout);
/* ここでパイプラインをフラッシュe */
total_timeout.tv_sec = 20;
clnt_stat = clnt_call(client, NULLPROC, xdr_void,
(caddr_t) NULL, xdr_void, (caddr_t) NULL,
total_timeout);
if (clnt_stat != RPC_SUCCESS) {
clnt_perror(client, "rpc");
exit(1);
}
clnt_destroy(client);
exit(0);
}
例 4-25 には、バッチ処理を使用した場合のサーバのディスパッチ部分を示します。サーバは、メッセージを送信しないので、クライアント側は、失敗に気付きません。
例 4-25 バッチ処理を行うサーバ
#include <stdio.h>
#include <rpc/rpc.h>
#include "windows.h"
void
windowdispatch(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
char *s = NULL;
switch(rqstp->rq_proc) {
case NULLPROC:
if (!svc_sendreply( transp, xdr_void, NULL))
fprintf(stderr, "can't reply to RPC call¥n");
return;
case RENDERSTRING:
if (!svc_getargs( transp, xdr_wrapstring, &s)) {
fprintf(stderr, "can't decode arguments¥n");
/* 呼び出し側にエラーを通知 */
svcerr_decode(transp);
break;
}
/* 文字列 s を処理するコードs */
if (!svc_sendreply( transp, xdr_void, (caddr_t) NULL))
fprintf( stderr, "can't reply to RPC call¥n");
break;
case RENDERSTRING_BATCHED:
if (!svc_getargs(transp, xdr_wrapstring, &s)) {
fprintf(stderr, "can't decode arguments¥n");
/* プロトコルエラーのため何も返さない */
break;
}
/* 文字列 s を処理するコード。ただし応答はしない。 */
break;
default:
svcerr_noproc(transp);
return;
}
/* 引数の復号化で割り当てた文字列を解放 */
svc_freeargs(transp, xdr_wrapstring, &s);
}
バッチ処理のパフォーマンス
バッチ処理によるパフォーマンスの向上を調べるために、例 4-23、例 4-24、例 4-25で 25144 行のファイルを処理しました。このサービスは、ファイルの各行を引き渡すだけの簡単なサービスです。バッチ処理を使用した方が、使用しない場合の 4 倍の速さで終了しました。
認証
この章でこれまでに示した例では、呼び出し側は自分自身の ID をサーバに示さず、サーバも呼び出し側の ID を要求しませんでした。ネットワークサービスによっては、ネットワークファイルシステムのように、呼び出し側の ID が要求される場合があります。『Solaris のシステム管理』を参照して、この節で説明したいずれかの認証の方法を実行してください。
RPC のクライアントとサーバを作成するときにさまざまなトランスポートを指定できるように、RPC クライアントにもさまざまなタイプの認証メカニズムを採用することができます。RPCの認証サブシステムは端点が開かれているので、認証はさまざな使用法がサポートされます。認証プロトコルは、付録 B 「RPC プロトコルおよび言語の仕様」で詳細に定義されています。
RPC が現在サポートしている認証タイプを 表 4-6 に示します。
表 4-6 RPC が現在サポートしている認証タイプ|
デフォルト。認証は実行されない。 |
|
|
UNIX オペレーティングシステムのプロセスパーミッションを基にした認証タイプ。 |
|
|
サーバよっては効率を上げるために AUTH_SYS の代わりに AUTH_SHORT を使用できる。AUTH_SYS 認証を使用するクライアントプログラムは、サーバからの AUTH_SHORT 応答ベリファイアを受信できる。詳細については、付録 B 「RPC プロトコルおよび言語の仕様」を参照のこと。 |
|
|
DES 暗号化技法を基にした認証タイプ。 |
|
呼び出し側が次の方法で RPC クライアントハンドルを新規作成すると、
clnt = clnt_create(host, prognum, versnum, nettype);
対応するクライアント作成ルーチンが次のように認証ハンドルを設定します。
clnt->cl_auth = authnone_create();
新たな認証インスタンスを作成するときは、auth_destroy(clnt->cl_auth) を使用して現在のインスタンスを破棄します。この操作はメモリの節約のために必要です。
サーバ側では、RPC パッケージがサービスディスパッチルーチンに、任意の認証スタイルが結合されている要求を渡します。サービスディスパッチルーチンに渡された要求ハンドルには、rq_cred という構造体が入っています。その構成は、認証資格タイプを示すフィールドを除いて、ユーザから隠されています。
/*
* 認証データ
*/
struct opaque_auth {
enum_t oa_flavor; /* 資格スタイル */
caddr_t oa_base; /* より詳細な認証データのアドレス */
u_int oa_length; /* 最大 MAX_AUTH_BYTES まで */
};
RPC パッケージでは、サービスディスパッチルーチンに対して次のことを保証しています。
-
svc_req 構造内の rq_cred フィールドは完全に設定済みです。したがって、rq_cred.oa_flavor を調べて認証タイプを得ることができます。得られた認証タイプが RPC でサポートされていない場合は、rq_cred のその他のフィールドも調べることができます。
-
サービス手続きに引き渡される rq_clntcred フィールドには NULL が入っているか、サポートされている認証資格タイプの設定済み構造体へのポインタが入っています。AUTH_NONE タイプには認証データはありません。rq_clntcred は、authdes_cred、short_hand_verf、 authkerb_cred、authdes_cred の各構造体へのポインタにだけキャストできます。
AUTH_SYS タイプの認証
クライアント側で AUTH_SYS (旧バージョンでは AUTH_UNIX) タイプの認証を使用するには、RPC クライアントハンドルの作成後に clnt->cl_auth を次のように設定します。
clnt->cl_auth = authsys_create_default();
以降は、この clnt を使用した RPC 呼び出しでは、clnt とともに以下に示す資格 - 認証構造体Failed Cross Reference Formatが渡されます。
例 4-26 AUTH_SYS タイプの資格 - 認証構造体
/*
* AUTH_SYS タイプの資格
*/
struct authsys_parms {
u_long aup_time; /* 資格作成時刻 */
char *aup_machname; /* クライアント側のホスト名 */
uid_t aup_uid; /* クライアント側の実効 uid */
gid_t aup_gid; /* クライアント側の現在のグループ ID */
u_int aup_len; /* aup_gids の配列の長さ */
gid_t *aup_gids; /* ユーザが所属するグループの配列 */
};
rpc.broadcast では、デフォルトで AUTH_SYS タイプの認証になります。
例 4-27 には、手続きを使用し、ネットワーク上のユーザ数を返すサーバプログラムである RUSERPROC_1() を示します。認証の例として AUTH_SYS タイプの資格をチェックし、呼び出し側の uid が 16 の場合は要求に応じないようにしてあります。
例 4-27 認証データをチェックするサーバプログラム
nuser(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
struct authsys_parms *sys_cred;
uid_t uid;
unsigned long nusers;
/* NULLPROC の場合は認証データなし */
if (rqstp->rq_proc == NULLPROC) {
if (!svc_sendreply( transp, xdr_void, (caddr_t) NULL))
fprintf(stderr, "can't reply to RPC call¥n");
return;
}
/* ここで uid を取得 */
switch(rqstp->rq_cred.oa_flavor) {
case AUTH_SYS:
sys_cred = (struct authsys_parms *) rqstp->rq_clntcred;
uid = sys_cred->aup_uid;
break;
default:
svcerr_weakauth(transp);
return;
}
switch(rqstp->rq_proc) {
case RUSERSPROC_1:
/* 呼び出し側が、この手続きの呼び出し資格を持っているかどうか確認 */
if (uid == 16) {
svcerr_systemerr(transp);
return;
}
/*
* ユーザ数を求めて変数 nusers に設定するコード
*/
if (!svc_sendreply( transp, xdr_u_long, &nusers))
fprintf(stderr, "can't reply to RPC call¥n");
return;
default:
svcerr_noproc(transp);
return;
}
}
このプログラムでは次の点に注意してください。
-
NULLPROC (手続き番号はゼロ) に結合した認証パラメタは、通常はチェックされません。
-
サービスプロトコルでは、アクセスが拒否された場合のステータスを返さなければなりません。例 4-27のプロトコルでは、その代わりに サービスプリミティブ svcerr_systemerr() を呼び出しています。
最後の点で重要なのは、RPC の認証パッケージとサービスの関係です。RPC は認証を処理しますが、個々のサービスへのアクセス制御は行いません。サービス自体でアクセス制御の方針を決め、それがプロトコル内で戻り値として反映されるようにしなければなりません。
AUTH_DES タイプの認証
AUTH_SYS タイプより厳しいセキュリティレベルが要求されるプログラムでは、AUTH_DES タイプの認証を使用します。AUTH_SYS タイプは AUTH_DES タイプに簡単に変更できます。たとえば、authsys_create_default() を使用する代わりに、プログラムから authsys_create() を呼び出し、RPC 認証ハンドルを変更して目的のユーザ ID とホスト名を設定することができます。
AUTH_DES タイプの認証を使用するには、サーバ側とクライアント側の両方のホストで、keyserv() デーモンと NIS また NIS+ ネームサービスが実行されている必要があります。また、両方のホスト上のユーザに対してネットワーク管理者が割り当てたパブリックキー / シークレットのキーペアが、publickey() のデータベースに入っていなければなりません。ユーザは keylogin() のコマンドを実行して自分のシークレットキーを暗号化しておく必要があります (通常は、ログインパスワードとセキュア RPC パスワードが同一の場合には、これを login() で行います)。
AUTH_DES タイプの認証を使用するには、クライアントが認証ハンドルを正しく設定しなければなりません。その例を次に示します。
cl->cl_auth = authdes_seccreate(servername, 60, server, (char *)NULL);
最初の引数は、サーバプロセスのネットワーク名か、サーバプロセスの所有者のネット名です。サーバプロセスは通常 root プロセスで、次の関数呼び出しでネット名を得ることができます。
char servername[MAXNETNAMELEN]; host2netname(servername, server, (char *)NULL);
servername は受信文字列へのポインタで、server はサーバプロセスが実行されているホスト名です。サーバプロセスがスーパーユーザ以外のユーザから起動されている場合は、次のように user2netname() を呼び出します。
char servername[MAXNETNAMELEN]; user2netname(servername, serveruid(), (char *)NULL);
serveruid() はサーバプロセスのユーザ id です。どちらの関数も最後の引数は、サーバを含むドメイン名です。NULL を指定すると、ローカルドメイン名が使用されます。
authdes_seccreate() の第 2 引数では、このクライアントの資格の存在時間 (ウィンドウとも呼ばれる) を指定します。この例では 60 秒が指定されているので、この資格はクライアント側が RPC 呼び出しを行なってから、60 秒間で失われます。プログラムから再びこの資格を使用しようとしても、サーバ側の RPC サブシステムは、資格がすでに失われていることを知って、資格を失ったクライアントからの要求に答えません。また資格の存在時間中に別のプログラムがその資格を再使用しようとしても拒否されます。サーバ側の RPC サブシステムが最近作成された資格を保存していて、重複して使用できないようにするためです。
authdes_seccreate() の第 3 引数は、クロックを同期させる timehost 名です。AUTH_DES タイプの認証を使用するには、サーバとクライアントの時間が一致していなければなりません。この例では、サーバに同期させています。(char *)NULL と指定すると同期しません。この指定は、クライアントとサーバがすでに同期していることが確実な場合にだけ行なってください。
authdes_seccreate() の第 4 引数は、タイムスタンプとデータとを暗号化するための DES 暗号化キーへのポインタです。この例のように (char *)NULL と指定した場合は、ランダムキーが選択されます。このキーは、認証ハンドルの ah_key フィールドに入っています。
サーバ側はクライアント側より簡単です。例 4-27のサーバを AUTH_DES タイプの認証を使用するように変更したものを、例 4-28に示します。
例 4-28 AUTH_DESタイプの認証を使用するサーバ
#include <rpc/rpc.h>
...
...
nuser(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
struct authdes_cred *des_cred;
uid_t uid;
gid_t gid;
int gidlen;
gid_t gidlist[10];
/* NULLPROC の場合は認証データなし */
if (rqstp->rq_proc == NULLPROC) {
/* 元のプログラムと同じ */
}
/* ここで uid を取得 */
switch(rqstp->rq_cred.oa_flavor) {
case AUTH_DES:
des_cred = (struct authdes_cred *) rqstp->rq_clntcred;
if (! netname2user( des_cred->adc_fullname.name, &uid,
&gid, &gidlen, gidlist)) {
fprintf(stderr, "unknown user: %s¥n",
des_cred->adc_fullname.name);
svcerr_systemerr(transp);
return;
}
break;
default:
svcerr_weakauth(transp);
return;
}
/* 以降は元のプログラムと同じ */
netname2user() ルーチンは、ネットワーク名 (またはユーザの netname) をローカルシステム ID に変換することに注意してください。このルーチンはグループ ID も返します (この例では使用していません)。
AUTH_KERB 認証形式
SunOS 5.x は、klogin 以外の Kerberos 4.0 の大部分のクライアント側機能をサポートします。AUTH_KERB は AUTH_DES と概念的に同じです。主要な違いは、DES がネットワーク名と暗号化された DES セッションキーを引き渡すのに対し、Kerberos は、暗号化されたサービスチケットを引き渡すことです。実装状態と相互運用性に影響を及ぼすその他の要因については、続けて説明します。
詳細は、kerberos(3N) マニュアルページと MIT Project Athena implementation of Kerberos の Steiner-Neuman-Shiller 報告書 [Steiner, Jennifer G., Neuman, Clifford, and Schiller, Jeffrey J. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, USENIX Association, カリフォルニア州, バークレー, June 1988.] を参照してください。MIT 文書には、athena-dist.mit.edu 上の FTP ディレクトリ、/pub/kerberos/doc または、ドキュメント URL、ftp://athena-dist.mit.edu/pub/kerberos/doc を使用して Mosaic でアクセスできます。
時刻の同期化
Kerberos はその資格が有効である時間ウィンドウの概念を使用します。クライアントまたはサーバのクロックを制限しません。クライアントは、サーバに指定されたウィンドウの時間を調整することによって、自身とサーバ間のずれを決定し、サーバに指定されたウィンドウ時間を調整することによって、この違いを補う必要があります。具体的には、window を authkerb_seccreate() に引き数として渡します。この場合、ウィンドウは変わりません。timehost が authkerb_seccreate() の引き数として指定されると、クライアント側は timehost から時刻を取得して、時刻の差異によってタイムスタンプを変更します。時刻を同期化するには、さまざまな方法が使用できます。詳細は、kerberos_rpc(3N) マニュアルページを参照してください。
周知の名前
Kerberos ユーザは、一次名、インスタンス、領域によって識別されます。RPC 認証コードは、領域とインスタンスを無視しますが、Kerberos ライブラリコードは無視しません。ユーザ名は、クライアントとサーバ間で同じであると仮定します。これによって、サーバは一次名をユーザ ID 情報に変換することができます。周知の名前として 2 つの書式が使用されます (領域は省略されます)。
-
root.host は、クライアント側 host の特権を与えられたユーザを表します。
-
user.ignored は、ユーザ名が user であるユーザを表します。インスタンは無視されます。
暗号化
Kerberos は、完全資格名 (チケットとウィンドウを含むもの) の送信時に暗号文ブロックチェイン (CBC: Cipher Block Chaining) モード、それ以外の場合は、電子コードブック (ECB: Electronic Code Book) モードを使用します。CBC と ECB は、DES 暗号化のための 2 つの方法です。詳細は、des_crypt(3) マニュアルページを参照してください。セッションキーは、CBC モードに対する初期入力ベクトルとして使用されます。表記は次のようになります。
xdr_type(object)
これは、XDR が object を type とみなして使用されることを示します。次のコードセクションの長さ (資格またはベリファイアのバイト数) を、4 バイト単位に丸めらたサイズで表されます。完全資格名およびベリファイアは、次のようになります。
xdr_long(timestamp.seconds) xdr_long(timestamp.useconds) xdr_long(window) xdr_long(window - 1)
セッションキーに等しい入力ベクトルを持つ CBC で暗号化を行うと、出力結果は次のような 2 つの DES 暗号化ブロックになります。
CB0 CB1.low CB1.high
xdr_long(AUTH_KERB) xdr_long(length) xdr_enum(AKN_FULLNAME) xdr_bytes(ticket) xdr_opaque(CB1.high)
xdr_long(AUTH_KERB) xdr_long(length) xdr_opaque(CB0) xdr_opaque(CB1.low)
xdr_long(timestamp.seconds) xdr_long(timestamp.useconds)
ニックネームは、ECB によって暗号化され、ECB0 と資格を得ます。
xdr_long(AUTH_KERB) xdr_long(length) xdr_enum(AKN_NICKNAME) xdr_opaque(akc_nickname)
xdr_long(AUTH_KERB) xdr_long(length) xdr_opaque(ECB0) xdr_opaque(0)
ポートモニタの使用
RPC サーバは、inetd や listen のようなポートモニタから起動できます。ポートモニタは、要求が来ているかどうか監視し、要求が来ればそれに応じてサーバを生成します。生成されたサーバプロセスには、要求を受信したファイル記述子 0 が渡されます。inetd の場合、サーバは処理を終えるとすぐに終了するか、次の要求がくる場合に備えて指定された時間だけ待ってから終了します。
listen の場合は常に新たなプロセスが生成されるため、サーバは応答を返したらすぐに終了しなければなりません。次に示す関数呼び出しでは、ポートモニタから起動されるサービスで使用する SVCXPRT ハンドルが作成されます。
transp = svc_tli_create(0, nconf, (struct t_bind *)NULL, 0, 0)
ここで、nconf は要求を受信したトランスポートの netconfig 構造体です。
サービスはポートモニタによりすでに rpcbind で登録されているので、登録する必要はありません。ただし、サービス手続きは次のように svc_reg() を呼び出して登録しなければなりません。
svc_reg(transp, PROGNUM, VERSNUM, dispatch,(struct netconfig *)NULL)
ここでは netconfig 構造体として NULL を渡し、svc_reg() が rpcbind を呼び出してサービスを登録しないようにしています。
注 -
rpcgen が生成したサーバ側スタブプログラムを調べて、これらのルーチンの呼び出し順序を確認してください。
接続型トランスポートの場合は、次のルーチンにより下位レベルインタフェースが提供されます。
transp = svc_fd_create(0, recvsize, sendsize);
最初の引数ではファイル記述子 0 を指定します。recvsize と sendsize には、適当なバッファサイズを指定できます。どちらの引数も 0 とすると、システムのデフォルト値が使用されます。自分で監視を行わないアプリケーションサーバの場合は、svc_fd_create() を使用します。
inetd の使用
/etc/inet/inetd.conf のエントリ形式は、ソケットサービス、TLI サービス、RPC サービスによってそれぞれ異なります。RPC サービスの場合の inetd.conf のエントリ形式は次のようになります。
rpc_prog/vers endpoint_type rpc/proto flags user pathname args
各エントリの内容を次に示します。
表 4-7 RPC inetd サービス|
rpc_prog/vers |
RPC プログラム名に / とバージョン番号 (またはバージョン番号の範囲) を付けたもの。 |
|
endpoint_type |
dgram (非接続型ソケット)、stream (接続型ソケット)、tli (TLI 端点) のどれか。 |
|
proto |
サポートされているトランスポートすべてを意味する *、nettype、netid のどれか。または、nettype と netid をコンマで区切ったリスト。 |
|
flags |
wait または nowait のどちらか。 |
|
user |
有効な passwd データベースに存在しているユーザ。 |
|
pathname |
サーバデーモンへのフルパス名。 |
|
args |
デーモンの呼び出し時に渡される引数。 |
エントリの例を次に示します。
rquotad/1 tli rpc/udp wait root /usr/lib/nfs/rquotad rquotad
inetd についての詳細は、inetd.conf(4) のマニュアルページを参照してください。
リスナの使用
次に示すように pmadm を使用して RPC サービスを追加します。
pmadm -a -p pm_tag -s svctag -i id -v vers ¥ -m `nlsadmin -c command -D -R prog:vers`
引数の -a はサービスの追加を意味します。-p pm_tag ではサービスへのアクセスを提供するポートモニタに結合したタグを指定します。-s svctag はサーバの ID コードです。-i id はサービス svctag に割り当てられた /etc/passwd 内のユーザ名です。-v vers はポートモニタのデータベースファイルのバージョン番号です。-m ではサービスを呼び出す nlsadmin コマンドを指定します。nlsadmin コマンドには引数を渡すことができます。たとえば、rusersd という名前の遠隔プログラムサーバのバージョン 1 を追加する場合は、pmadm コマンドは次のようになります。
# pmadm -a -p tcp -s rusers -i root -v 4 ¥ -m `nlsadmin -c /usr/sbin/rpc.ruserd -D -R 100002:1`
このコマンドでは、root パーミッションが指定され、listener データベースファイルのバージョン 4 でインストールされ、TCP トランスポート上で使用可能になります。pmadm の引数やオプションは複雑であるため、RPC サービスはコマンドスクリプトでもメニューシステムでも追加できます。メニューシステムを使用するには、sysadm ports と入力して、port_services オプションを選択します。
サービスを追加した場合は、その後リスナを再初期化してサービスを利用可能にしなければなりません。そのためには、次のようにリスナを一度止めてから再起動します (このとき rpcbind が実行されていなければならないことに注意してください)。
# sacadm -k -p pmtag # sacadm -s -p pmtag
リスナプロセスの設定などについての詳細は、listen(1M)、pmadm(1M)、sacadm(1M)、sysadm(1M) のマニュアルページ、『TCP/IP とデータ通信』を参照してください。
サーバのバージョン
一般に、プログラム PROG の最初のバージョンは PROGVERS_ORIG とし、最新バージョンは PROGVERS と命名します。プログラムのバージョン番号は続き番号で割り当てなければなりません。バージョン番号に飛ばされた番号があると、検索したときに定義済みのバージョン番号を探し出せないようなことが起こります。
プログラムのバージョン番号は、プログラムの所有者以外は決して変更してはいけません。自分が所有していないプログラムのバージョン番号を追加したりすると、そのプログラムの所有者がバージョン番号をインクリメントするときに重大な問題が起こります。バージョン番号の登録やご質問はご購入先へお問い合わせ下さい。
ruser プログラムの新バージョンが、long ではなく unsigned short を返すように変更されたとします。新バージョンの名前を RUSERSVERS_SHORT とすると、新旧の 2 つのバージョンをサポートするサーバは二重登録することになります。次のように、どちらの登録でも同じサーバハンドルを使用します。
例 4-29 同一ルーチンの 2 つのバージョンのためのサーバハンドル
if (!svc_reg(transp, RUSERSPROG, RUSERSVERS_ORIG,
nuser, nconf))
{
fprintf(stderr, "can't register RUSER service¥n");
exit(1);
}
if (!svc_reg(transp, RUSERSPROG, RUSERSVERS_SHORT, nuser,
nconf)) {
fprintf(stderr, "can't register RUSER service¥n");
exit(1);
}
次のように、1 つの手続きで両バージョンを実行できます。
例 4-30 両バージョンを使用するサーバ
void
nuser(rqstp, transp)
struct svc_req *rqstp;
SVCXPRT *transp;
{
unsigned long nusers;
unsigned short nusers2;
switch(rqstp->rq_proc) {
case NULLPROC:
if (!svc_sendreply( transp, xdr_void, 0))
fprintf(stderr, "can't reply to RPC call¥n");
return;
case RUSERSPROC_NUM:
/*
* ユーザ数を求めて変数 nusers に設定するコード
*/
switch(rqstp->rq_vers) {
case RUSERSVERS_ORIG:
if (! svc_sendreply( transp, xdr_u_long, &nusers))
fprintf(stderr, "can't reply to RPC call¥n");
break;
case RUSERSVERS_SHORT:
nusers2 = nusers;
if (! svc_sendreply( transp, xdr_u_short, &nusers2))
fprintf(stderr, "can't reply to RPC call¥n");
break;
}
default:
svcerr_noproc(transp);
return;
}
return;
}
クライアントのバージョン
異なるホストでは RPC サーバの異なるバージョンが実行されている可能性があるので、クライアントはさまざまなバージョンに対応できるようにしなければなりません。たとえば、あるサーバでは旧バージョン RUSERSPROG(RUSERSVERS_ORIG) が実行されており、別のサーバでは最新バージョン RUSERSPROG(RUSERSVERS_SHORT) が実行されているとします。
サーバのバージョンがクライアント作成ルーチン clnt_call() で指定したバージョン番号と一致しない場合は、clnt_call() から RPCPROGVERSMISMATCH というエラーが返されます。サーバがサポートしているバージョン番号を取り出して、正しいバージョン番号をもつクライアントハンドルを作成することもできます。そのためには、例 4-31 のルーチンを使用するか、clnt_create_vers() を使用します。詳細については、rpc(3N) のマニュアルページを参照してください。
例 4-31 クライアント側での RPC バージョン選択
main()
{
enum clnt_stat status;
u_short num_s;
u_int num_l;
struct rpc_err rpcerr;
int maxvers, minvers;
CLIENT *clnt;
clnt = clnt_create("remote", RUSERSPROG, RUSERSVERS_SHORT,
"datagram_v");
if (clnt == (CLIENT *) NULL) {
clnt_pcreateerror("unable to create client handle");
exit(1);
}
to.tv_sec = 10; /* タイムアウト値を設定 */
to.tv_usec = 0;
status = clnt_call(clnt, RUSERSPROC_NUM, xdr_void,
(caddr_t) NULL, xdr_u_short,
(caddr_t)&num_s, to);
if (status == RPC_SUCCESS) { /* 最新バージョン番号が見つかった場合 */
printf("num = %d¥n", num_s);
exit(0);
}
if (status != RPC_PROGVERSMISMATCH) { /* その他のエラーr */
clnt_perror(clnt, "rusers");
exit(1);
}
/* 指定したバージョンがサポートされていない場合 */
clnt_geterr(clnt, &rpcerr);
maxvers = rpcerr.re_vers.high; /* サポートされている最新バージョン */
minvers = rpcerr.re_vers.low; /* サポートされている最も古いバージョン */
if (RUSERSVERS_SHORT < minvers || RUSERSVERS_SHORT > maxvers)
{
/* サポート範囲内にない場合 */
clnt_perror(clnt, "version mismatch");
exit(1);
}
(void) clnt_control(clnt, CLSET_VERSION, RUSERSVERS_ORIG);
status = clnt_call(clnt, RUSERSPROC_NUM, xdr_void,
(caddr_t) NULL, xdr_u_long, (caddr_t)&num_l, to);
if (status == RPC_SUCCESS)
/* 識別できるバージョン番号が見つかった場合 */
printf("num = %d¥n", num_l);
else {
clnt_perror(clnt, "rusers");
exit(1);
}
}
一時的な RPC プログラム番号の使用
場合によっては、動的に生成される RPC プログラム番号をアプリケーションが使用すると便利なことがあります。たとえば、コールバック手続きを実装する場合などです。コールバックでは、クライアントプログラムは通常、動的に生成される、つまり一時的な RPC プログラム番号を使用して RPC サービスを登録し、これを要求とともにサーバに渡します。次にサーバは一時的な RPC プログラム番号を使用してクライアントプログラムをコールバックし、結果を返します。クライアントの要求を処理するのにかなりの時間がかかり、クライアントが停止できない (シングルスレッドであると仮定して) 場合などには、この機構が必要になります。このような場合、サーバはクライアントの要求を認識し、あとで結果とともにコールバックを行います。コールバックを使用する別の例としては、サーバから定期的なレポートを生成する場合があります。クライアントは RPC 呼び出しを行い、報告を開始します。そしてサーバはクライアントプログラムが提供する一時的な RPC プログラム番号を使用して、定期的にレポートとともにクライアントをコールバックします。
動的に生成される一時的な RPC 番号は、0x40000000 から 0x5fffffff の範囲です。次に示すルーチンは指定されるトランスポートタイプ用に、一時的な RPC プログラムに基づいてサービスを作成します。サービスハンドルと一時的な rpc プログラム番号が返されます。呼び出し側はサービスディスパッチルーチン、バージョンタイプ、トランスポートタイプを提供します。
例 4-32 一時的な RPC プログラム - サーバ側
SVCXPRT *
register_transient_prog(dispatch, program, version, netid)
void (*dispatch)(); /* サービスディスパッチルーチン */
u_long *program; /* 一時的な RPC 番号が返される */
u_long version; /* プログラムバージョン */
char *netid; /* トランスポート id */
{
SVCXPRT *transp;
struct netconfig *nconf;
u_long prognum;
if ((nconf = getnetconfigent(netid)) == (struct netconfig
*)NULL)
return ((SVCXPRT *)NULL);
if ((transp = svc_tli_create(RPC_ANYFD, nconf,
(struct t_bind *)NULL, 0, 0)) == (SVCXPRT *)NULL) {
freenetconfigent(nconf);
return ((SVCXPRT *)NULL);
}
prognum = 0x40000000;
while (prognum < 0x60000000 && svc_reg(transp, prognum,
version,
dispatch, nconf) == 0) {
prognum++;
}
freenetconfigent(nconf);
if (prognum >= 0x60000000) {
svc_destroy(transp);
return ((SVCXPRT *)NULL);
}
*program = prognum;
return (transp);
}
- © 2010, Oracle Corporation and/or its affiliates