サーバへのアクセスを制御する (OpenWindows ユーザーズガイド (上級編))

OpenWindows ユーザーズガイド (上級編)

サーバへのアクセスを制御する

openwin を -noauth オプションとともに使用していない場合は (「デフォルトの認証プロトコルの変更」を参照してください) 、ユーザベースとホストベースのアクセス制御機構が両方ともアクティブ状態になります。サーバは最初にユーザベースの制御機構をチェックした後、ホストベースの制御機構をチェックします。デフォルトのセキュリティ構成では、MIT-MAGIC-COOKIE-1 がユーザベースの制御機構として使われ、空のアクセスリストがホストベースの制御機構として使われます。ホストベースのアクセスリストは空であるため、実質的にはユーザベースの制御機構だけが有効になります。-noauth オプションを指定すると、サーバはユーザベースのアクセス制御機構を無効にし、ホストベースのアクセスリストにローカルホスト名を追加してリストを初期化します。

xhost と xauth の 2 つのプログラムのどちらかを使って、サーバのアクセス制御機構を変更できます。詳細は、マニュアルページを参照してください。これらのプログラムは、認証プロトコルによって作成される 2 つのバイナリファイルにアクセスします。これらのファイルには、各セッション固有の認証データが入っています。一方のファイルは、サーバから内部的に使用するためのもので、もう一方のファイルは下記のファイル名でユーザの $HOME ディレクトリにあります。

.Xauthority

(クライアント認証ファイル)

サーバ上にあるホストベースのアクセスリストを変更するには、xhost プログラムを使用します。これにより、アクセスリストに対するホストの追加と削除ができます。デフォルトの構成 (空のホストベースのアクセスリスト) で OpenWindows を起動した場合は、xhost を使ってアクセスリストにマシン名を追加すると、セキュリテレベルを低下させます。つまりサーバは、デフォルトの認証プロトコルで指定されるユーザの他に、リストに追加されたホストに対してもアクセスを許可します。ホストベースのアクセス制御機構のセキュリテレベルが低いと見なされる理由については、「ホストベース」を参照してください。

xauth プログラムは、.Xauthority クライアントのファイル内の認証プロトコルデータにアクセスします。アクセスを操作する側のユーザは自分の .Xauthority ファイルからデータを抽出して、他のユーザがそのデータを自分の .Xauthority ファイルにマージできるようにします。これにより、操作側ユーザのサーバまたはそのユーザが接続しているサーバに対して他のユーザがアクセスできるようになります。

xhost と xauth の使用例は、「MIT-MAGIC-COOKIE-1 を使用する場合のアクセス許可」を参照してください。

クライアント認証ファイル

クライアント用の許可ファイル .Xauthority には、次の形式のエントリがあります。

connection-protocol          auth-protocol          auth-data

デフォルト設定では、.Xauthority ファイルに auth-protocol として MIT-MAGIC-COOKIE-1 が格納され、ローカル表示に関するエントリが connection-protocol および auth-data としてのみ格納されます。たとえば、ホスト anyhost 上の .Xauthority ファイルに次のエントリが格納されている場合が考えられます。

anyhost:0       MIT-MAGIC-COOKIE-1  82744f2c4850b03fce7ae47176e75
localhost:0      MIT-MAGIC-COOKIE-1  82744f2c4850b03fce7ae47176e75
anyhost/unix:0  MIT-MAGIC-COOKIE-1   82744f2c4850b03fce7ae47176e75

クライアントの起動時に、connection-protocol に対応するエントリが .Xauthority から読み取られ、auth-protocol および auth-data が接続パケットの一部としてサーバに送られます。デフォルトの構成では、xhost によって、空のホストベースのアクセスリストが戻され、認証が実行可能な状態であることを示します。

認証プロトコルをデフォルトの MIT-MAGIC-COOKIE-1 から SUN-DES-1 に変更した場合、.Xauthority ファイルのエントリには、auth-protocol として SUN-DES-1 が格納され、auth-data としてユーザのネットワーク名 (netname) が格納されます。netname の形式は次のとおりです。

unix.userid@NISdomainname

たとえば、ホスト anyhost 上で .Xauthority ファイルに次のエントリが格納されている場合が考えられます。この unix.15339@EBB.Eng.Sun.COM は、マシンに依存しないユーザの netname です。

anyhost:0        SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"
localhost:0       SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"
anyhost/unix:0   SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"

注 -

自分のネットワーク名、またはマシンに依存しないネットワーク名が不明な場合は、システム管理者に問い合わせてください。

`MIT-MAGIC-COOKIE-1` を使用する場合のアクセス許可

MIT-MAGIC-COOKIE-1 認証プロトコルを使用している場合は、次の手順により自分のサーバに他のユーザがアクセスできるようにすることができます。

サーバを実行しているマシン上で xauth を実行し、hostname:0 に対応するエントリを抽出して、ファイルに入れます。

例として、hostname が anyhost、ファイルが xauth.info の場合を示します。
myhost% /usr/openwin/bin/xauth nextract - anyhost:0 > $HOME/xauth.info

アクセスを要求しているユーザに、手順 1 で作成したエントリが入っているファイルを送ります。(mailtool、rcp、またはその他のファイル転送プログラムを使用します。)

注 -
認証情報が入っているファイルの転送には、rcp よりもメールを使用するほうがより安全です。rcp を使用する場合は、他のユーザが簡単にアクセスできるディレクトリにそのファイルを入れないようにしてください。

他のユーザは、エントリを自分の .Xautority ファイルにマージしなければなりません。

例として、userhost が xauth.info を自分の .Xauthority ファイルにマージする場合を示します。
userhost% /usr/openwin/bin/xauth nmerge - < xauth.info
注 -
auth-data は特定のセクションに対応します。したがって、サーバが再起動されるまでの間、有効です。

`SUN-DES-1` を使用する場合のアクセス許可

SUN-DES-1 認証プロトコルを使用している場合は、次の手順により自分のサーバに他のユーザがアクセスできるようにすることができます。

サーバを実行しているマシン上で xhost を実行しサーバに新規ユーザを通知します。

例として、新規ユーザ somebody に myhost 上での実行を許可する場合を示します。
myhost% xhost + somebody@

新規ユーザは、xauth を使用して自分の .Xauthority ファイルにエントリを追加します。

例として、新規ユーザのマシンに依存しない netname が、unix.15339@EBB.Eng.Sun.COM の場合を示します。下記のコマンドは、途中に Return キーなどを入れずに 1 行に入力しなければならないことに注意してください。パイプ記号の後に、空白と続いてコマンドの残りの部分を入力します。
userhost% echo 'add myhost:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM"' | $OPENWINHOME/bin/xauth