Solaris X Window System 開発ガイド

サーバーに対するアクセスの操作

openwin コマンドで -noauth オプションを指定しなければ (デフォルト認証プロトコルの変更を参照)、ユーザーベースとホストベースの両方のアクセス制御機構がアクティブ状態となります。サーバーは、最初にユーザーベース機構を調べ、次にホストベース機構を調べます。デフォルトのセキュリティコンフィギュレーションでは、ユーザーベース機構として MIT-MAGIC-COOKIE-1、ホストベース機構に対して空リストが使用されます。ホストベースのリストが空であるため、アクティブになるのはユーザーベース機構です。-noauth オプションを指定すると、サーバーはユーザーベースのアクセス制御機構をアクティブでない状態とします。また、ローカルホストを追加することによってホストのベースリストが初期化されます。

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

表 7–1


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

サーバー中のホストベースアクセスリストを変更するには、xhost プログラムを使用します。これにより、アクセスリストに対するホストの追加および削除が可能です。最初にデフォルトのコンフィギュレーションである空のホストベースアクセスリストを使用し、xhost によってマシン名を追加するという方法は、セキュリティレベルを低下させます。すなわち、追加されたホストがアクセスを許可されるだけでなく、デフォルト認証プロトコルを指定するすべてのユーザーもアクセスが許可されます。ホストベースアクセス制御機構のセキュリティレベルが低いと見なされる理由は前述のホストベースの項で説明した通りです。

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

xhost および xauth の使用例は後述のMIT-MAGIC-COOKIE-1 を使用する場合のアクセス許可に示してあります。

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

クライアント認証ファイル .Xauthority のエントリには以下の形式があります。

表 7–2


`connection-protocol`	`auth-protocol`	`auth-data`

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

表 7–3


`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 によって空のホストベースアクセスリストが戻され、認証が実行可能な状態であることを示します。

認証プロトコルをデフォルトから SUN-DES-1 に変更した場合、.Xauthority には auth-protocol として SUN-DES-1 が格納され、auth-data としてユーザーのネット名が格納されます。ネット名の形式は次の通りです。

unix.userid@NISdomainname

たとえば、ホスト anyhost 上で、.Xauthority ファイルに以下のエントリが格納されているという場合が考えられます。

表 7–4


`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`”

この unix.15339@EBB.Eng.Sun.COM は、マシン独立であるユーザーのネット名です。

注 –

自分のネットワーク名、またはマシン独立のネット名が不明のときは、システム管理者に照会してください。

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

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

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

例として、hostname が anyhost、ファイルが xauth.info である場合を示します。
```
myhost%$OPENWINHOME/bin/xauth

nextract - anyhost:0 >

$HOME/xauth.info
```

エントリが入っているファイルを、アクセスを要求しているユーザーに送る (メールツール、rcp またはその他のファイル転送プロトコルを使用する)。

注 –
認証情報が格納されたファイルの転送には、rcp よりもメールを使用した方がより安全です。rcp を使用する場合は、他のユーザーが容易にアクセスできるディレクトリにそのファイルを入れないようにしなければなりません。

他のユーザーはエントリを自分の .Xauthority ファイルに併合しなければならない。

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

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

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

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

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

新しいユーザーは、xauth を使用してエントリを自分の .Xauthority ファイルに追加しなければならない。

例として、新しいユーザー somebody のマシン独立のネット名が unix.15339@EBB.Eng.Sun.COM である場合を示します。
```
userhost%echo 'addmyhost:0SUN-DES-1

“unix.15339@EBB.Eng.Sun.COM”'

| $OPENWINHOME/bin/xauth
```