test

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

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

通常、システム上のすべてのアプリケーションは、ローカルマシンで実行されるプログラムです。ただし、使用しているワークステーションがネットワークの一部であれば、リモートマシン上でアプリケーションを実行してその結果をローカルマシンの画面に表示できます。ほかのマシンでアプリケーションを実行すれば、ローカルマシン上の資源を節約できる上、ネットワーク上のすべてのアプリケーションにアクセスできます。

この節では、リモートマシン上でアプリケーションを実行してその結果をローカルマシンの画面に表示する方法を紹介します。ネットワークアプリケーションの実行に関連した補足情報については、セキュリティに関する詳細を参照してください。

注 –

ネットワークアプリケーションを実行するための処理は、コンピュータ環境によって異なる可能性があります。

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

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

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

リモートマシンに存在するネットワークアプリケーションを実行するには、次のように環境変数を設定する必要があります。

次に、rlogin コマンドを使用してリモートマシン上でアプリケーションを実行するための手順を示します。

リモートマシンでアプリケーションを実行する方法

  1. リモートマシンの表示ができるように、ローカルマシン上で xhost コマンドを実行します。


    starbug$ xhost + venus

  2. リモートマシンにログインします。


    starbug$ rlogin venus -l user2

Password: 

Last login: Wed Nov  1 16:06:21 from starbug

Sun Microsystems Inc.   SunOS 5.9       Generic February 2002

  3. DISPLAY 変数をローカルマシンに設定します。


    venus$ DISPLAY=starbug:0.0

  4. DISPLAY 変数をローカルマシンにエクスポートします。


    venus$ export DISPLAY

  5. アプリケーションを実行します。


    venus$ bigprogram &

このアプリケーションとの対話は画面上のほかのアプリケーションとまったく同様に行われますが、このアプリケーションの実行はリモートマシンで行われます。

このような方法でアプリケーションを実行すると、ローカルマシンにインストールされているアプリケーションよりもコンピュータ資源の消費を小さく抑えられるという利点があります。アクセスが認められているリモートアプリケーションを実行する場合はこの方法を利用できます。

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

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

対象読者

リモートサーバでアプリケーションを実行する場合以外は、少なくとも Solaris オペレーティング環境のデフォルトのセキュリティ構成を変更する必要はありません。

アクセス制御機構

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


Xlib: connection to hostname refused by server

Xlib: Client is not authorized to connect to server

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


AUDIT: <Date Time Year>: X: client 6 rejected from IP 129.144.152.193 

   port 3485	Auth name: MIT-MAGIC-COOKIE-1

アクセス制御機構には、 ユーザベースとホストベースの 2 種類があります。ユーザベースの機構は特定のユーザのアカウントに対するアクセスを許可し、ホストベースの機構は特定のホスト (マシン) に対するアクセスを許可します。Xsun に -noauth オプションを指定しないと、これらのアクセス制御機構はどちらもアクティブ状態になります。詳細は、サーバへのアクセスを制御するを参照してください。

ユーザベース

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

ホストベース

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

Solaris 環境では、ホストベースの制御機構は、下位互換性を目的として使用されます。

注 –

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

認証プロトコル

Solaris オペレーティング環境は、以下の2 種類の認証プロトコルをサポートしています。 MIT-MAGIC-COOKIE-1 と SUN-DES-1 です。これらの 2 種類のプロトコルでは、使用される認証デー タの形式は異なりますが、アクセス制御機構は似ています。Solaris オペレーティング環境のデフォルトは、ユーザベース機構を使用した 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 を使ってそのユーザのサーバにアクセスする方法はありませんが、マジッククッキーを使うと可能な場合もあります。

このプロトコルは、Solaris 1.1 環境および Solaris 1.1 互換環境に入っているライブラリでしか使用できません。静的ライブラリで構築されたアプリケーションは、この認証プロトコルを使用できません。

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

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

デフォルトの認証プロトコル MIT-MAGIC-COOKIE-1 は、システムでサポートされるもう 1 つの認証プロトコル SUN-DES-1 に変更できます。また、ユーザベースのアクセス制御機構をまったく使わないようにすることもできます。デフォルト認証プロトコルを変更するには、 /usr/dt/config/Xservers ファイルの Xsun という行を編集します。たとえば、デフォルトを MIT-MAGIC-COOKIE-1 から SUN-DES-1 に変更するには、/usr/dt/config/Xservers ファイルの次の行を編集して Xsun コマンドに -auth sun-des オプションを加えます。 


:0  Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -auth sun-des

ユーザベースのアクセス制御機構を使わないで Solaris オペレーティング環境を実行する必要がある場合は、/usr/dt/config/Xservers ファイル内の次の行を編集して Xsun コマンドに -noauth オプションを加えます。 


:0  Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -noauth
注意 – 注意 –

-noauth オプションを指定した場合、セキュリティの水準は低下します。この設定は、OpenWindows をホストベースのアクセス制御機構だけで実行した場合と同じです。サーバはユーザベースのアクセス制御機構を無効にします。あるマシンでアプリケーションを実行できるユーザであれば、そのマシンのサーバに対するアクセスを許可されることになります。

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

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

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

サーバ上にあるホストベースのアクセスリストを変更するには、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.Sun.COM”

localhost:0      SUN-DES-1            ”unix.15339@EBB.Sun.COM”

anyhost/unix:0   SUN-DES-1            ”unix.15339@EBB.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 で作成したエントリが入っているファイルを送ります。

    この送信には、電子メールツールや 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 ファイルにエントリを追加します。

    例として、新規ユーザの、マシンに依存しないネット名が unix.15339@EBB.Sun.COM の場合を示します。下記のコマンドは、途中に Return キーなどを入れずに 1 行に入力しなければならないことに注意してください。パイプ記号のあとに、空白と続いてコマンドの残りの部分を入力します。


    userhost% echo 'add myhost:0 SUN-DES-1 “unix.15339@EBB.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 上に表示されます。