test

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

付録 D ネットワークアプリケーションの実行

この付録では、ネットワーク上の他のマシンにあるアプリケーションを実行できる、OpenWindows 環境の高度な機能について説明します。

注 -

ユーザの大部分はこの付録を参照する必要はありません。ネットワークアプリケーションの可能性を研究してみたい場合は、システム管理者に問い合わせてネットワーク上で実行できる適当なアプリケーションを紹介してもらってください。

通常の OpenWindows 環境では、画面上のすべてのアプリケーション (メールツールやカレンダマネージャなど) は、ローカルマシン上で実行されるプログラムです。ただし、使用しているワークステーションがネットワークの一部であれば、リモートマシン上でアプリケーションを実行してその結果をローカルマシンの画面に表示できます。この方法でアプリケーションを実行すれば、ローカルマシン上の資源を節約できる上、ネットワーク上のすべてのアプリケーションにアクセスできます。

この付録では、リモートマシン上でアプリケーションを実行して、その結果をローカルマシンの画面に表示する最も簡単な方法を紹介します。使用しているマシンの環境はそれぞれ異なるため、次の説明は柔軟に解釈する必要があります。「セキュリティに関する詳細」では、ネットワークアプリケーションを実行する際の複雑さについて解説しています。

次の手順に従ってリモートマシン上のアプリケーションを実行するには、次の要件を満たしている必要があります。

これらの要件を満たしているかどうか不明な場合は、システム管理者に問い合わせてください。

rlogin を使用してネットワークアプリケーションを実行する

リモートマシン上でネットワークアプリケーションを実行するには、環境変数の設定が適切でなくてはなりません。

下記は、rlogin を使用してリモートマシン上でコマンドツールを実行する例です。この例では、ホームディレクトリはリモートマシンの /home/mydirectory にマウントされ、OpenWindows はリモートマシンの /usr/openwin にあります。mydirectory および mymachine という変数は、実際の設定に応じて適当に変更してください。また、cmdtool の部分は任意のアプリケーション名で置き換えることができます。

$ rlogin remotemachine
   .
   .
(以下のコマンドはリモートマシン上で実行される)
   .
   .
$ HOME=/home/mydirectory
$ DISPLAY=mymachine:0
$ LD_LIBRARY_PATH=/usr/openwin/lib
$ /usr/openwin/bin/cmdtool &

最終行を入力すると、コマンドツールのウィンドウがローカルマシンの画面に表示されます。このコマンドツールは、画面上の他のアプリケーションとまったく同様に操作できますが、実際にはリモートマシン上で実行されています。

このような方法でコマンドツールを実行する利点は特にありませんが (コマンドツールはローカルマシンですでに利用可能であり、コンピュータ資源もそれ程使用しません)、この例は、リモートマシン上にあるアプリケーションの利用方法を示しています。

セキュリティに関する詳細

この節では、ネットワーク上でアプリケーションを実行するときに必要と思われるネットワークセキュリティの基本事項について説明します。具体的には次のような事項です。

対象読者

次のどれかの構成でアプリケーションを実行する場合以外は、OpenWindows バージョン 3.3 以降のデフォルトのセキュリティ構成を変更する必要はありません。

アクセス制御機構

アクセス制御機構は、どのクライアントまたはアプリケーションが X11 サーバにアクセスできるかを制御します。アクセスが許可されたクライアントだけがサーバに接続できます。アクセスが許可されていないその他のクライアントはすべて次のエラーメッセージを表示して終了します。 

Xlib: connection to hostname refused by server
Xlib: Client is not authorized to connect to server

接続の結果は、次のようにサーバコンソールに表示されます。

AUDIT: <月日 時刻 年>: X: client 6 rejected from IP 129.144.152.193 port 3485
Auth name: MIT-MAGIC-COOKIE-1

アクセス制御機構には、ユーザベースとホストベースの 2 種類があります。(つまり、前者は特定のユーザのアカウントにアクセスを許可し、後者は特定のホスト、すなわちマシンにアクセスを許可します。) openwin とともにに -noauth オプションを指定しないと、ユーザベースとホストベースのアクセス制御機構が両方ともアクティブ状態となります。詳細は、この付録で後述の 「サーバへのアクセスを制御する」を参照してください。

ユーザベース

ユーザベースすなわち認証ベースのアクセス制御機構では、あるユーザに対し、任意のホストマシン上の特定のユーザに対するアクセスが明示的に許可されます。ユーザのクライアントは、サーバに認証データを渡します。そのデータがサーバの認証データと一致すれば、そのホストのすべてのユーザはサーバのアクセスを許可されます。

ホストベース

ホストベースのアクセス制御機構には、汎用性があります。この機構では、特定のホストへのアクセスを許可し、そのホスト上のすべてのユーザがサーバに接続できるようにします。これは、ゆるやかなアクセス制御方式です。ホストにサーバに対するアクセス権が与えられていれば、そのホスト上のすべてのユーザがサーバに接続できます。

Solaris 環境では、ホストベースの制御機構は、下位互換性を目的として使用されます。X11R4 または OpenWindows バージョン 2 より前のバージョンの Xlib や libcps を使ってリンクされたアプリケーションでは、新しいユーザベースのアクセス制御機構に対応できません。これらのアプリケーションがサーバに接続できるようにするためには、ホストベース機構に切り換えるか、あるいは新しいバージョンの Xlib と libcps にリンクし直さなければなりません。

注 -

旧バージョンの Xlib や libcps とリンクしたクライアントは、できれば新バージョンのライブラリを使ってリンクし直してください。これにより、新しいユーザベースのアクセス制御機構の下でサーバに接続できるようになります。

認証プロトコル

OpenWindows は、MIT-MAGIC-COOKIE-1 と SUN-DES-1 の 2 種類の認証プロトコルをサポートしています。これらの 2 種類のプロトコルでは、使用される認証データの形式は異なりますが、アクセス制御機構は似ています。サーバに実装できるのは 1 種類のプロトコルに限られます。OpenWindows のデフォルトは、ユーザベースのアクセス制御機構を使用した MIT-MAGIC-COOKIE-1 プロトコルです。

MIT-MAGIC-COOKIE-1

MIT-MAGIC-COOKIE-1 認証プロトコルは、マサチューセッツ工科大学で開発されました。サーバの起動時に、サーバとシステムを起動したユーザについてマジッククッキー (magic cookie) が作成されます。接続を要求するたびに、ユーザのクライアントは、接続パケットの一部としてマジッククッキーをサーバに送信します。このマジッククッキーは、サーバのマジッククッキーと比較されます。マジッククッキーが一致すれば接続は許可され、一致しなければ拒否されます。

SUN-DES-1

米国 Sun Microsystems, Inc. が開発した SUN-DES-1 認証プロトコルは、機密保護 RPC (遠隔手続き呼び出し) に基づいており、DES (データ暗号化ソフトウェア) を必要とします。認証情報としては、マシンに依存しないユーザの netname (ネットワーク名) が使われます。この認証情報は暗号化され、接続パケットの一部としてサーバに送信されます。サーバは暗号化された認証情報を復号化して、netname が登録されているものであれば接続を許可します。

SUN-DES-1 プロトコルは、MIT-MAGIC-COOKIE-1 よりも高水準のセキュリティを提供します。あるユーザが他のユーザの netname を使ってそのユーザのサーバにアクセスする方法はありませんが、マジッククッキーを使うと可能な場合もあります。

このプロトコルは、OpenWindows バージョン 3 以降の環境に入っているライブラリでしか使用できません。OpenWindows バージョン 3 より前の環境の静的ライブラリ、特に Xlib で構築されたアプリケーションは、この認証プロトコルを使用できません。

「SUN-DES-1 を使用する場合のアクセス許可」では、他のユーザの netname を自分のサーバのアクセスリストに追加することによって、自分のサーバに対する他のユーザのアクセスを許可する方法について説明しています。

デフォルトの認証プロトコルの変更

デフォルトの認証プロトコル MIT-MAGIC-COOKIE-1 は、システムでサポートされるもう 1 つの認証プロトコル SUN-DES-1 に変更できます。また、ユーザベースのアクセス制御機構をまったく使わないようにすることもできます。デフォルト設定の変更は、openwin コマンドのオプションを指定することによって行います。たとえば、デフォルトを MIT-MAGIC-COOKIE-1 から SUN-DES-1 に変更するには、次のオプションを指定して OpenWindows を起動します。 

example% openwin -auth sun-des

ユーザベースのアクセス制御機構を使わないで OpenWindows を実行する場合は、-noauth コマンド行オプションを指定します。 

example% openwin -noauth

注意 - 注意 -

-noauth オプションを指定した場合、セキュリティの水準は低下します。この設定は、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 認証プロトコルを使用している場合は、次の手順により自分のサーバに他のユーザがアクセスできるようにすることができます。

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

    例として、hostname が anyhost、ファイルが xauth.info の場合を示します。

    myhost% /usr/openwin/bin/xauth nextract - anyhost:0 > $HOME/xauth.info

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

    注 -

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

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

    例として、userhost が xauth.info を自分の .Xauthority ファイルにマージする場合を示します。

    userhost% /usr/openwin/bin/xauth nmerge - < xauth.info

    注 -

    auth-data は特定のセクションに対応します。したがって、サーバが再起動されるまでの間、有効です。

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

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

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

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

    myhost% xhost + somebody@

  2. 新規ユーザは、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

クライアントをリモートで実行する場合とローカルで実行する場合

X クライアントは、環境変数 DISPLAY の値を使用して接続するサーバ名を取り出します。

クライアントをリモートで実行するか、または他のユーザとしてローカルで実行するには、次の手順を実行します。

  1. サーバを実行しているマシン上で、他のユーザのアクセスを許可します。

    使用する認証プロトコルに応じて、「MIT-MAGIC-COOKIE-1 を使用する場合のアクセス許可」または 「SUN-DES-1 を使用する場合のアクセス許可」で説明した手順を実行します。

  2. 環境変数 DISPLAY の値として、サーバを実行しているホスト名に設定します。

    例として、ホスト名が remotehost の場合を示します。

    myhost% setenv DISPLAY remotehost:0

  3. クライアントプログラムを実行します。

    myhost% client_program&

    クライアントは、リモートマシン remotehost 上に表示されます。