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 -' を使わな ければなりません。