X サーバは magic cookie を使って、ユーザの X サーバへのアクセスを 制御できます。これは本質的に機械向けに書かれた、乱数から生成され たアクセスコードです。各クライアントはアクセスの許可をしてもらう前 に同じ magic cookie の値をサーバに提供しなければなりません。この値 はファイル .Xauthority に保持されます。それは 各セッションの開始時に X Display Manager かユーザのどちらかによっ て作成されます。
一台のマシンへのログオンしかしないユーザなら、セキュリティの強化と いう課題は残ってはいますが、話は簡単です。そのマシン上のユーザによっ て実行されたそれぞれの新しいクライアントはその magic cookie を見つ けて問題無く起動するでしょう。しかし、多くのユーザは同時に複数のマ シン上で作業します。リモートマシン上の X クライアントはその magic cookie が何かどうやって知るのでしょう？これは xauth プログラムの機 能が解決します。
xauth プログラムはユーザの magic cookie の認証情報を変更および表 示するために使われます。magic cookie が人に読める形で表示されれ ば、リモートホストに送ることができます。そのリモートホスト上でユー ザの .Xauthority ファイルの中に magic cookie をマージするために、xauth をもう一度使います。ユーザ用の .rhosts ファイルが設定されているなら、リモートホスト (ahost.foo.org とします) へ認証情報を押入れることは次の一行のコ マンドでできます。
xauth extract - $DISPLAY | rsh ahost.foo.org xauth merge -
|
最初のコマンドは使用中のホスト ($DISPLAY) 用の magic cookie を標準出力 (ダッシュ) に印字します。次にこの情報はリモー トシェルコマンドへパイプされて、マシン ahost.foo.org 上で xauth プログラムを実行します。そして magic cookie は標準入力 (二つ目の ダッシュ) から読まれて、.Xauthority ファイ ルの中にマージされます。その結果、このコマンドを実行したユーザは ahost.foo.org 上の X クライアントを起動し、それらを X サーバ上に 表示できるようになります。.Xauthority ファ イルのパーミッションを正しく設定することが重要です。所有者だけが 読み書きできるようにします ('-rw-------' に 設定します)。さらに、ホームディレクトリをリードオンリーでも NFS でエキスポートしないように気をつけてください！マウントされるかも しれず、.Xauthority ファイルを読むことを許 してしまいます。
ここで、何が主に改善されたのかに注意してください。現在、このコマ ンドを実行したユーザは、ahost.foo.org 上のそのユーザ唯一人で、彼 だけがその X サーバへ X クライアントを接続できます。依然として ahost.foo.org 上の他のすべてのユーザはこの X セッションの外にブ ロックされます。
X Display Manager, xdm はログインスクリーン を複数の X サーバに供給するクライアントです。ユーザが X Display Manager を介してログインする時、xdm はユー ザのホームディレクトリにあるファイル .Xauthority の中へ magic cookie を書きます。 X サーバは独立型のコンピュータであるとは限りません。唯一の機能が 他のシステムからのクライアントを実行する X 端末でも可能です。こ の手のマシンは xdm が最初のログインスクリー ンを表示することを必要とします。独立型のコンピュータでも xdm を利用するかもしれません。多くのユーザ に使いやすいログイン手順を提供する以外に、 xdm は magic cookie による認証のサポートも 提供します。この認証は初めにファイル /usr/lib/X11/xdm/xdm-config 内の次に示す X リソースのエントリをオンにしなければなりません -
DisplayManager*authorize: true
|
これで xdm はユーザがログインするたびに新し い magic cookie を生成して、ユーザの .Xauthority ファイルの中にその値を格納しま す。
xdm を使わない場合でも、この認証方式を使う ことができます - このことは次の項で述べます。
Xdm はあなた用の .Xauthority ファイルを管理しますが、 xdm を使わなくても magic cookie 認証は可能 です。多くのサーバ上で、ユーザが magic key の値を生成する必要が あるということが問題なだけです (OpenWindows は例外の一つで、起動 された時にそれは magic cookie を生成します)。これは様々な方法で 行うことができます。例えば、Korn シェルを使っている場合、シェル に組み込まれている乱数生成機能を使えます -
randomkey=`ksh -c 'echo $(( $RANDOM * $RANDOM * 2 ))'`
xauth add ${HOST}:0.$randomkey
|
ksh を使ってない場合、clock が '乱数 key' を得るために使えるでしょ う -
randomkey=`date +"%y%m%d%H%M%S"`
xauth add ${HOST}:0 . $randomkey
|
Xrsh は X11R5 が提供するスクリプトで contrib/clients/xrsh ディレ クトリにあります。rsh を介しリモートのクライアントを実行するユー ザにとって、これは便利なスクリプトです。これはリモートのクライア ントを実行する前に自動的にリモートマシンへ magic cookikie code をコピーするために xauth を利用します、例えばホスト foo 上の xterm ウィンドウを実行するには -
xrsh -auth xauth foo xterm
|
認証は host-by-host ではなく、user-by-user の基準で行われます。 一つのホストがとても多いユーザをサポートする環境において、これは 非常に重要なことです。
xdm と xauth プログラムは管理者とエンドユー ザが使用および維持するのに時間のかかるものです。ユーザの方で X のクライアントサーバモデルをよく理解していることが必要です。
magic cookie 認証は xhost のセキュリティに 加えて、使わなければなりません。実際にはすべてのホストに基づくア クセスを無効にするために 'xhost -' を使わな ければなりません。