Remote X Apps mini-HOWTO Vincent Zweije (zweije@xs4all.nl) 11 July 2000 The Linux Japanese FAQ Project (JF@linux.or.jp) v0.6.3j1, 29 March 2001 この mini-HOWTO はリモート X アプリケーションを実行する方法について説 明します。つまり、X のプログラムを実行しているコンピュータとは異なると ころに表示をさせる方法です。逆にいいますと、X のプログラムをあなたが対 面しているコンピュータではないところで実行させる方法、となります。この mini-HOWTO の焦点はセキュリティです。さらに X アプリケーションをローカ ルで、ただし異なったユーザ ID で、実行させる情報も含んでいます。 ______________________________________________________________________ 目次 1. はじめに 2. 関連した読み物 3. 想定する状況 4. ちょっとした理論 5. クライアントに指定する 6. サーバに指定する 6.1 xhost 6.2 xauth 6.2.1 クッキーを作る 6.2.2 クッキーの転送 6.2.2.1 ホームディレクトリの共有 6.2.2.2 リモートシェル rsh を使う 6.2.2.3 Telnet を使い手動で行う 6.2.2.4 Telnet で自動に行う方法 6.2.3 クッキーを使う 6.3 SSH 7. 別のユーザ ID からの X アプリケーション 7.1 同一ホスト上の異なるユーザ 7.2 クライアントユーザが root 8. リモートウィンドウマネージャの実行 9. トラブルシューティング 10. 日本語訳について ______________________________________________________________________ 1. はじめに この mini-HOWTO はリモート X アプリケーションを扱うためのガイドです。 これを書いた理由はたくさんあります。 1. 「リモート X アプリケーションを実行するには？」という質問が usenet で多い。 2. X 接続の許可に「xhost +hostname を使え」とか、ひどいのになると 「xhost + を使え」というようなアドバイスをうんざりするほど目にす る。xhost は途方もないセキュリティ上の問題があり、もっとよい方法が ある。 3. xhost 以外のもっとよい方法を記述した簡単な文書を知らない。もし、他 の簡単な文書を知っているなら著者 zweije@xs4all.nl に教えてくださ い。 このドキュメントは UNIX ライクなシステムを対象に書かれています。ローカ ルかリモートのどちらかのオペレーティングシステムが UNIX 系でなくても、 この文書で動作の仕組みを見つけられるかもしれません。しかしながら、例と して書いたことは各自のシステムに合わせて変更しなければならないでしょ う。 このドキュメントの最新版は http://www.xs4all.nl/~zweije/xauth.html で 入手できます。また「Remote X Apps mini-HOWTO」として http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps で入手できま す。Linux (mini-)HOWTO は sunsite.unc.edu から http か ftp で入手でき ます。 このバージョンは 0.6.3 です。善意により公開されており、無保証です。提 案、アイディア、追加、役立つポインタ、(打ち間違い等の)訂正などを募集し ています。でも、この文書は簡単で読み易い文書に保っておきたいと思ってい ます。最もよい意味での HOWTO 形式ですね。いちゃもんは /dev/null へ。 内容の最終更新は 2000年06月11日 に Vincent Zweije が行いました。 2. 関連した読み物 "What to do when Tk says that your display is insecure" という関連ド キュメントが WWW 上の http://ce-toolkit.crd.ge.com/tkxauth/ (日本語訳) にあります。 Kevin Kenny 氏によって書かれたものです。このドキュメント (xauth) では X 認証についてこの文書と同じような解決方法を提案していま す。しかし Kevin は xauth の制御に xdm を用いることの方を中心にしてい るようです。 O'Reilly and Associates の The X System Window System Vol. 8 X "Window System Administrator's Guide" もまたよい情報源なので注意を惹かれます。 あいにく著者はチェックできていません。 さらにもう一つのドキュメントは "Securing X Windows" というタイトルです ぐにでも読めるものです。 http://ciac.llnl.gov/ciac/documents/ciac2316.html から入手できます。 comp.windows.x、comp.os.linux.x や comp.os.linux.networking の usenet ニュースグループもチェックしてください。 3. 想定する状況 ２台のコンピュータを使っています。１台目で、入力と表示のために X ウィ ンドウシステムを使っています。２台目をいくつかの重要なグラフィックの仕 事に使っています。１台目のディスプレイに２台目の出力を表示させたい。 X ウィンドウシステムはこれができます。 もちろんネットワーク接続が必要です。X プロトコルはネットワークを大食い するので、なるべく速いものが必要です。ですがちょっとの我慢と適切なプロ トコル圧縮を使えば、モデム経由でアプリケーションを実行することもできま す。 X プロトコル圧縮については dxpc http://www.vigor.nu/dxpc/ か LBX http://www.paulandlesley.org/faqs/LBX-HOWTO.html (またの名を LBX mini-HOWTO という) をチェックしてください。 １台目のディスプレイに２台目の出力を表示するには、以下の２つのことをし なければなりません。 1. リモートコンピュータからの接続を受け付けるよう、ローカルディスプレ イ (サーバ) に指定する。 2. ローカルディスプレイにその出力を行うよう、リモートアプリケーション (クライアント) に指定する。 4. ちょっとした理論 マジックワードは DISPLAY です。X ウィンドウシステムでは、ディスプレイ は (単純化して) キーボード、マウス、スクリーンから成ります。ディスプレ イはサーバプログラムによって管理されます。これは X サーバと呼びならわ されています。このサーバは、サーバに接続する他のプログラムに表示能力を 与えます。 ディスプレイは名前で表されます。例えば： o DISPLAY=light.uni.verse:0 o DISPLAY=localhost:4 o DISPLAY=:0 ディスプレイの表記はホスト名 (例示した light.uni.verse や localhost)、 コロン(:)、番号 (例示した 0 や 4 ) から成ります。ディスプレイの表記の ホスト名は X サーバを実行しているコンピュータの名前です。ホスト名を省 略すると、ローカルホストを示すことになります。番号は普通 0 です――１ 台のコンピュータに複数のディスプレイが接続されているのなら、別の値にな るかもしれません。 上記のディスプレイ表記に .n が添えられることもあります。この .n はスク リーン番号を指しています。ディスプレイは複数のスクリーンを持つことがで きます。普通は (番号 n=0 の) ひとつのスクリーンしかないので、これが既 定値になっています。 他の DISPLAY の書式もありますが、上記の書式で本書の目的を行うには十分 です。 技術的な興味のために： o hostname:D.S はホスト hostname のディスプレイ番号 D のスクリーン番 号 S を意味します――この表記のディスプレイのための X サーバは TCP ポート 6000+D をリッスンします。 o host/unix:D.S はホスト host のディスプレイ番号 D のスクリーン番号 S を意味します――この表記のディスプレイのための X サーバは UNIX ドメ インソケット /tmp/.X11-unix/XD をリッスンします (なので host からし か到達できません)。 o :D.S は host/unix:D.S と等価です。ここで host はローカルのホスト名 です。 5. クライアントに指定する クライアントプログラム (例としてグラフィックアプリケーション) は DISPLAY 環境変数を調べて接続するディスプレイを知ります。しかし、クライ アント起動時のコマンドライン引数に -display hostname:0 を与えた場合 は、この設定を優先します。いくつかの例で明らかにしましょう。 私たちのコンピュータは外部からホスト名 light として見えており、ドメイ ン uni.verse に所属しているとします。普通に X サーバを実行しているな ら、ディスプレイは light.uni.verse:0 として識別されます。 dark.matt.er というリモートコンピュータで描画プログラムの xfig を実行し、ローカルマ シン light に xfig の出力を表示させたいと思います。 すでにリモートコンピュータ dark.matt.er に telnet していると想定しま す。 リモートコンピュータで csh を使っているなら dark% setenv DISPLAY light.uni.verse:0 dark% xfig & とするか、あるいは dark% xfig -display light.uni.verse:0 & とします。 リモートコンピュータで sh を使っているなら dark$ DISPLAY=light.uni.verse:0 dark$ export DISPLAY dark$ xfig & とするか、あるいは dark$ DISPLAY=light.uni.verse:0 xfig & とします。もちろん dark$ xfig -display light.uni.verse:0 & でもいいです。 (訳注； dark$ env DISPLAY=light.uni.verse:0 xfig& なら csh でも sh でも使えますね :) ) telnet の種類によっては、自動的にリモートホストへ DISPLAY 変数を転送す るものもあるようです。そんな telnet を使用するなら、ディスプレイの指定 を手動で行なわなくてもよいので、幸運でしょう。 telnet の殆どは TERM 環 境変数を転送する種類なので賢くやるなら、TERM 環境変数に DISPLAY 変数の 内容を代入して代用させることです。 代用するのと同様の考え方で、次のような数行のスクリプトで実現できます。 telnet する前に、TERM に DISPLAY の値を加える。telnet する。 リモートコンピュータの適切な .*shrc ファイルで、TERM から DISPLAY の値を読む。 6. サーバに指定する サーバはどこからの接続でも受け付けるわけではありません。あなたのスクリ ーンにすべての人がウィンドウを表示できるなんて、嬉しくないですよね。あ なたの入力を読まれたくもないでしょう――キーボードはディスプレイの一部 であるということを忘れないで下さい。 ディスプレイへのアクセス許可が、セキュリティリスクの原因になることを理 解している人はほとんどいません。あなたのディスプレイにアクセスできる人 は、スクリーンを読み書きでき、あなたのキーストロークを読むことやマウス の動きを読むこともできます。 ほとんどのサーバは接続の認証方法が２つあります――host リスト機構 (xhost) とマジッククッキー機構 (xauth) です。また ssh(secure shell) は X 接続を転送することができます。 6.1. xhost xhost は host 名にもとづいてアクセスを許します。サーバは、接続を許され た host のリストを管理します。host のチェックを完全に無効にすることも できます。注意してください――無効にするとチェックをしなくなるので全て の host が接続できます！ xhost プログラムを用いるとサーバの host リストを制御できます。前述の例 でこの機構を使うには light$ xhost +dark.matt.er とします。 これはホスト dark.matt.er からの接続をすべて許します。X クライアントが 接続されウィンドウが表示されたら、すぐに安全のため接続許可を取り消しま す。それには light$ xhost -dark.matt.er とします。 host のチェックを無効にするには light$ xhost + とします。 これは host のアクセスチェックを無効にしているので、すべての人に接続を 許しています。信用できないユーザーがいるネットワーク (例えばインター ネット) 上では決してアクセスチェックを無効にしないでください。host の チェックを再度有効にするには light$ xhost - でできます。 "xhost -" は、アクセスリストから全部のホストを削除するわけではありませ ん (もしそうなら、不便極まりません――どこからも、ローカルホストさえか らも接続できなくなります)。 xhost はとても危なっかしい機構です。xhost はリモートホスト上のユーザを 区別できませんし、 host 名 (実際にはアドレス) も偽ることができます。も し信用できないユーザがいるネットワーク (例えばインターネットにダイアル アップ PPP アクセス) にいるなら、これは良くないことです。 (訳注：アドレスを偽れる理由。xhost において X サーバが維持するリストは 数値が登録されています。host 名を使って登録した場合でも gethostbyname 関数によりその IP アドレスが数値となります。ですので、４バイトの数値に なります。 X サーバがアクセスチェックをする時に使用するのは、X クライ アントが送出した IP パケットのソース IP アドレスを使用するのではありま せん。データ部に X クライアントが乗せた任意の数値です。X クライアント のプログラムの作りにより何でも乗せることができます。訳者が以前使用した ことのあるメーカ製ワークステーションは、hostid の値を乗せていまし た。hostid の既定値は inittab の中で、プライマリの IP アドレスを定義し てるだけでした。この場合は、クラッキングプログラムを書かずとも、数行の スクリプトを書くだけで、ブルドーザアタックが行えます。) 6.2. xauth xauth は正しい機密を知っている人にアクセスを許します。そのような機密は 認証レコードあるいはマジッククッキーと呼ばれます。この認証スキームの正 式な呼称は MIT-MAGIC-COOKIE-1 です。 異なるディスプレイに対するそれぞれクッキーは、~/.Xauthority にまとめて 格納されます。~/.Xauthority はグループユーザおよび他ユーザにはアクセス できないようにしなければなりません (訳注：chown 600 .Xauthority として おきます)。xauth プログラムはこれらのクッキーを管理します。それ故にこ のスキームのニックネームは xauth といいます。 セッションを始める際、サーバは -auth の引数で指定したファイルからクッ キーを読みます。その後サーバは同じクッキーを知るクライアントの接続のみ 許します。接続が確立された後で ~/.Xauthority のクッキーが変更されても サーバはこの変更を取り出しません。 最近のサーバは照会したクライアント用のクッキーをすぐに作ることができま す。しかし、クッキーはサーバ内に保存されたままです――クライアントが ~/.Xauthority にクッキーを追加しない限り ~/.Xauthority には入りませ ん。David Wiggins氏によると あなたが興味を示すような名案が X11R6.3 で追加されました。新 しいセキュリティ拡張を通して、X サーバはすぐに新しいクッキー を作って返すことができます。さらにクッキーを「信用しない」よ うに指定できるので、そのようなクッキーで接続を行ったアプリケ ーションは次のように操作を制限されます。例えば他の信用できる クライアントのキーボード/マウスの入力やウィンドウに表示され ている内容を盗めなくなります。簡単でないにしても、少なくとも この機能を使うことができる新しいサブコマンド "generate" が xauth にあります。 xauth は xhost に比べてセキュリティに優れています。また特定のコンピュ ータの特定のユーザだけにアクセスを制限することができます。xhost のよう に偽ったアドレスからの接続はできません。必要なら xauth の後で接続を許 すために xhost を使うこともできます。 6.2.1. クッキーを作る xauth を使いたいのなら、-auth authfile 引数を付けて、X サーバを起動し なければなりません (訳注：authfile は認証ファイルを指す PATH)。 startx スクリプトを使うのなら、xinit の右側に記述します。以下のようにして startx スクリプトの中で認証レコードを作成します。 /usr/X11R6/bin/startxからの引用： mcookie|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority" mcookie は util-linux パッケージにある小さなプログラムで、 ftp://ftp.math.uio.no/pub/linux/ から入手できます。あるいは、 md5sum を用いて無作為データ (例えば /dev/urandom や ps -axl) をクッキー形式に 変換 (massage) することもできます。 dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority" root になれず startx スクリプトを編集できないのなら、システム管理者に statx スクリプトを適切に設定してもらうか、あるいは xdm を設定しても らってください。管理者ができないもしくはしないなら、 ~/.xserverrc スク リプトで実現できます。このスクリプトがあると、 xinit は実際の X サーバ の代わりにこのファイルを実行します。したがって、このスクリプトから実際 の X サーバを適切な引数で起動できます。こうするには、 ~/.xserverrc に 上記のマジッククッキーの行を書いてクッキーを作らせ、次いで X サーバを 起動する行を書きます。 #!/bin/sh mcookie|sed -e 's/^/add :0 . /'|xauth -q exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority" X セッションの管理に xdm を使うなら、xauth を簡単に使用できます。 /etc/X11/xdm/xdm-config の中に DisplayManager.authDir リソースを定義し てください。xdm は X サーバが起動する時に -auth 引数を渡すようになりま す。xdm のもとでログインした時、xdm は ~/.Xauthority にクッキーを置き ます。詳しくは xdm(1) の man ページを参照して下さい。例えば著者の /etc/X11/xdm/xdm-config では以下の行が書かれています。 DisplayManager.authDir: /var/lib/xdm 6.2.2. クッキーの転送 サーバホスト light.uni.verse で X セッションを開始し、 ~/.Xauthority の中にクッキーを持ちました。次はクライアントホスト dark.matt.er へクッ キーを転送する必要があります。これには、たくさんの方法があります。 6.2.2.1. ホームディレクトリの共有 light と dark 上のあなたのホームディレクトリが共有されていれば一番簡単 です。両方の ~/.Xauthority ファイルは同じなので、即座にクッキーは転送 されます。しかし落とし穴があります――~/.Xauthority に :0 のためのクッ キーを置いた時、dark は light のためのクッキーと考えずに自身のための クッキーだと考えます。クッキーを作る時、明示的なホスト名を使うべきです ――これを省略することはできません。次のような、ちょっとした sed の技 を使えば、:0 と light:0 の両方のために同じクッキーを置くことができま す。 #!/bin/sh mcookie|sed -e 's/^/add :0 . /' -e p -e "s/:/$HOST&/"|xauth -q exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority" 6.2.2.2. リモートシェル rsh を使う ホームディレクトリが共有されていないのなら、リモートシェル rsh による 方法でクッキーを転送できます。 light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge - とします。これは 1. ローカルの ~/.Xauthority からクッキーを抽出する (xauth nlist :0)。 2. dark.matt.er に転送する (| rsh dark.matt.er)。 3. 転送先の ~/.Xauthority に置く (xauth nmerge -)。 を行います。 ${HOST} の使い方に注意してください。ローカルホストと明示的に関連づけら れたクッキーを転送する必要があります。リモート X アプリケーションは ディスプレイの値 :0 をリモートマシンのものと解釈します。これはやりたい こととは違うでしょう？ 6.2.2.3. Telnet を使い手動で行う rsh が動作しないこともあります。また rsh はセキュリティ上の欠点もあり ます (著者の記憶が正しいなら、これも host 名を偽れます)。 rsh を使えな いか使わないなら以下のように手動でクッキーを転送できます。 light$ echo $DISPLAY :0 light$ xauth list $DISPLAY light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926 light$ rlogin dark.matt.er Password: dark% setenv DISPLAY light.uni.verse:0 dark% xauth Using authority file /home/zweije/.Xauthority xauth> add light.uni.verse:0 . 076aaecfd370fd2af6bb9f5550b26926 xauth> exit Writing authority file /home/zweije/.Xauthority dark% xfig & [15332] dark% logout light$ 詳しくは rsh(1)、xauth(1x) を参照して下さい。 6.2.2.4. Telnet で自動に行う方法 リモートホストへ telnet する時に、TERM か DISPLAY 変数にクッキーを代入 して代用させることができます。これは TERM 変数に DISPLAY 変数を代用さ せるのと同じ方法で実行できるでしょう。セクション 5 の「``クライアント に指定する''」を参照してください。これについては異論のある方もいらっ しゃるでしょう。この方法で本当にうまくいくのかどうか、あるいは駄目なの か、という点を知りたいので、もし実際に検証できた人がいれば結果を著者ま で送っていただけたら幸いです。 (訳注：クッキーは元々ネットワーク透過です。しかし、X はマルチプラット フォーム環境なので、充分なテストが必要であるということだと思われま す。) でも注意、他の UNIX では、別のユーザからでも環境変数を見ることができる こともあります。そんな場合、 $TERM の中に入れたクッキーを他人に見えな いようにするすべはありません。 6.2.3. クッキーを使う dark.matt.er 上の (前述の xfig のような) X アプリケーションは、認証に 使うクッキーを自動的に ~/.Xauthority から読みます。 localhost:D を使う時は、ちょっとした問題があります。X クライアントアプ リケーションは、クッキー検索の目的のために localhost:D を host/unix:D と解釈します。実際には、~/.Xauthority に localhost:D のクッキーを置く 方法は効果がありません。 考えてみれば、単に論理に従っているに過ぎないことがわかるでしょう。 localhost の解釈は、それを解釈するマシンに完全に左右されます。NFS など でホームディレクトリを共有すると、たくさんのホストで各々の他のクッキー が全て干渉しあって、ひどい状態に陥ることになるでしょう。 6.3. SSH 認証レコードは暗号化されずにネットワークを経由して送信されます。誰かが 接続をのぞく心配があるなら、ssh(secure shell) を使ってください。これは 暗号化された接続を経由して X を転送します。それにまた、ほかにもすばら しいことがあります。それはシステムの構造改善です。ssh ホームページ http://www.ssh.org/ を見てください。 誰か認証スキームや暗号化 X 接続について他に何か知っていませんか？ kerberosかな？ 訳注： Kerberosについて、うえやま るいさん、岡本さんからのコメントをま とめました： ケルベロスはギリシャ神話に出てくる冥界の支配者ハデスの飼い犬で３ つの頭をもち冥界の門を守る番犬です。"Kerberos" は MIT の "Athena" 計画の一貫として研究開発されました。RFC 1510 が 1993 年 に発行されてます。 Kerberos は信頼できないネットワークで安全な認証・通信を行うため に、信頼できる第三者を使うシステムです。内部の暗号は 対称鍵暗 号DESを使います。DESなのであまり強くはありません。しかし、チケッ トという仕組で認証を行うので運用が簡単で、安全な認証と通信ができ ます。鍵配布センターを階層化して、大規模なシステムにも対応するこ ともできるようです。 ふつうの方法だと、クライアントがサーバを利用するときは相手が本当 に本物であるか互いに分かりません。そこで、お互いが信頼している第 三者に身元保証してもらえばよいという考えに基づいています。その第 三者が鍵配布センターというもので、その鍵配布センターにサーバを利 用するためのチケットを発行してもらいます。だれでもチケットを発行 してもらえるわけはなくクライアントとサーバの鍵を登録しておく必要 があります。鍵配布センターに発行してもらったチケットは、クライア ント(発行してもらう側) の鍵で暗号化されているので、これを復号で きるということは、クライアントは確かに本人であることがわかりま す(本人じゃなければチケットを取りだせないので、サーバを利用する ことはできません)。 チケットは復号化した中に入っていて、このチケットはサーバの鍵で暗 号化されています。そこで「サーバがチケットを復号化できる = サー バも確かに本人である」ということになります(復号化した中にセッ ション鍵が入っていて、それ以降の通信でこのセッション鍵を使うのた め、本人以外は続行できません)。 この欠点は、チケットの再利用ができてしまうところです。攻撃者はチ ケットの内容を見れませんが、流れているチケットを拾ってそのままも う一回サーバに送れば本人のふりをできます。そのために、タイムスタ ンプを暗号化して一緒に送ります。古いタイムスタンプ付きのチケット は使えません。それに、サーバはタイムスタンプを記録しているので、 まったく同じスタンプを持つチケットは無効です。 システム全体での欠点は、鍵配布センターが存在することです。鍵すべ てを登録しているので、ここを破られると安全もなにもありません。 XFree86 のマニュアルの翻訳(岡本さん)が JF にあります。 X の認証 関係の参考にしてください。また、国内では OPEN DESIGN No.14 CQ 出 版社 ISBN4-7898-1806-3 C3055 \1748Eの「集中特集最新の暗号による セキュリティの実現」が参考になります。 ポインタ： FreeBSDハンドブックのペー ジ：http://www.freebsd.org/ja_JP.EUC/handbook/handbook64.html#66 http://www.releenet.co.jp/bsd/handbook/handbook60.html Jun Kuwamuraさんのページ：http://stealth.rccm.co.jp/~juk/krb/ 7. 別のユーザ ID からの X アプリケーション root 特権の必要な、グラフィカルな設定ツールを実行したいとしましょう。 しかし、 X セッションは普通のアカウントで実行しています。始めは奇妙に 思うかもしれませんが、X サーバはツールがディスプレイにアクセスすること を許しません。 root で普通に何かしたい時に、どうすれば可能ですか？そし てどうすればこの問題を回避できますか？ ユーザ ID clientuser で X アプリケーションを起動したいが X セッション は serveruser で起動されているという、一般的な状況にしましょう。クッキ ーのセクションを読んでいれば、なぜ clientuser がディスプレイにアクセス できないのか分かるはずです。 ~clientuser/.Xauthority はディスプレイにアクセスするための正 しいマジッククッキーを含んでいません。正しいクッキーは ~serveruser/.Xauthority にあります。 7.1. 同一ホスト上の異なるユーザ もちろん、リモート X で動作するものは、異なるユーザ ID の X でも同じよ うに動作します (端的には slogin localhost -l clientuser)。クライアント ホストとサーバホストがたまたま同じだというだけです。しかし、両方のホス トが同じ時、マジッククッキーの転送には近道があります。 ユーザ ID の切り替えに su を使うと仮定します。基本的に、行わなければな らないことは、su を呼ぶスクリプトを書き、そこで su の行うコマンドを、 リモート X に必要な処理を行う適切なコードでラップすることです。必要な 処理とは DISPLAY 変数の設定とマジッククッキーの転送です。 DISPLAY の設定は比較的簡単です――su コマンドを実行する前に、その引数 として DISPLAY="$DISPLAY" を定義するだけです。以下のようにします。 su - clientuser -c "env DISPLAY=$DISPLAY clientprogram &" これだけでは動作しません。さらにクッキーの転送を行う必要があります。 クッキーの取得は xauth list "$DISPLAY" を使えば可能です。このコマンド がクッキーのリストに用いる書式は、たまたま xauth add コマンドに与える 際の書式に合致しています――ちょうど必要としていたものです。 当然パイプでクッキーを渡したいところです。残念ながら、su はその標準入 力からパスワードを読もうとするので、su コマンドにパイプで渡すことは簡 単ではありません。ここでも都合のいいことには、シェルスクリプトの内部で はファイル記述子をいじり回すことができますので、これが可能になります。 clientuser と clientprogram をパラメータ化し汎用化したスクリプトを書き ます。読みやすさは少し犠牲にして頑強になるように、スクリプトを改善しま しょう。以下のようになります。 #!/bin/sh if [ $# -lt 2 ] then echo "usage: `basename $0` clientuser command" >&2 exit 2 fi CLIENTUSER="$1" shift # FD 4 becomes stdin too exec 4>&0 xauth list "$DISPLAY" | sed -e 's/^/add /' | { # FD 3 becomes xauth output # FD 0 becomes stdin again # FD 4 is closed exec 3>&0 0>&4 4>&- exec su - "$CLIENTUSER" -c \ "xauth -q <&3 exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*' 3>&-" } ほとんどの状況で、移植性と動作に十分だと考えます。現在著者が考えうる欠 点は、'$*' を使っているため、 command 内部でシングルクォートを用いると su コマンドの引数 ('$*') が壊れてしまうことです。もし他にもなにか深刻 な間違いがあったら、著者に email を書き送ってください。 スクリプトを /usr/local/bin/xsu とすれば xsu clientuser 'command &' とできます。 パスワードを使う限り、これ以上そう簡単にはできません。ええ、(sudo) を 使う方法もありますね。でもここでは扱いません。 7.2. クライアントユーザが root 当然、root ではないクライアントユーザが root で動作することも同様にで きます。しかし、root はすべての人の ~/.Xauthority ファイルを読むことが できるので、root の場合はより簡単です。クッキーを送る必要がありませ ん。 DISPLAY 環境変数を設定し、XAUTHORITY が ~serveruser/.Xauthority を見るように設定するだけです。つまり: su - -c "exec env DISPLAY='$DISPLAY' \ XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \ command" これをスクリプト中に書くと以下のようになるでしょう。 #!/bin/sh if [ $# -lt 1 ] then echo "usage: `basename $0` command" >&2 exit 2 fi su - -c "exec env DISPLAY='$DISPLAY' \ XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \ "'"$SHELL"'" -c '$*'" スクリプトを /usr/local/bin/xroot とすれば xroot 'control-panel &' とできます。 でも、もし xsu をすでに設定してあれば、このようにしなければならない理 由はありません。 8. リモートウィンドウマネージャの実行 ウィンドウマネージャ (twm、wmaker や fvwm95 のような) は他のアプリケー ションと同様に扱えます。普通の手順で動かせます。 ほとんどの場合うまくいきます。最高で一つのウィンドウマネージャをいつで もディスプレイで実行できます。すでにローカルウィンドウマネージャが実行 されているのなら、リモートウィンドウマネージャを起動することはできませ ん (それは不平を言い終了するでしょう)。最初にローカルウィンドウマネー ジャを kill(または単に quit) しなければなりません。 残念ながら、多くの X セッションスクリプトはこの１行で終わります。 exec window-manager-of-choice そして、これは (ローカルの)ウィンドウマネージャが終了した時に、セッ ションが終了することを意味します。 X システム (xdm か xinit) にセッ ションが終了したとみなされると、実際にはログアウトさせられてしまいま す。 いくつか特別なことを行わなければなりませんが、実行は可能でそんなに難し くありません。あなたが欲するとおりに、セッションスクリプト (普通は ~/.xsession か ~/.xinitrc) をちょっといじるだけです。 多くの場合、ウィンドウマネージャは新しいプログラムの実行方法を提供しま すが、それで実行したプログラムはローカルマシン上で実行されることに注意 してください。ここで言うローカルとはウィンドウマネージャが起動している マシンを指します。リモートでウィンドウマネージャを実行した場合は、リモ ートのアプリケーションが起動されます。これはあなたの希望とは異なるかも しれません。もちろん、リモートで起動したプログムは、依然として手元の ディスプレイに表示を行います。 9. トラブルシューティング 初めてリモート X アプリケーションを実行しようとしても、大抵はそのまま では動作しません。以下２〜３のエラーメッセージ、原因、解決方法を挙げま す。 xterm Xt error: Can't open display: DISPLAY 環境変数がなく、またアプリケーションに -display フラグも指定し ていません。アプリケーションは空の文字列を想定しますが、構文上無効で す。この解決には、DISPLAY 環境変数を正しく設定しておきます (シェルに よって setenv か export のどちちらかを使います)。 _X11TransSocketINETConnect: Can't connect: errno = 101 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 エラー 101 は "Network is unreachable" です。アプリケーションはサーバ にネットワーク接続できません。DISPLAY の設定が正しいかどうかと、サーバ マシンにクライアントから到達できるかどうか (サーバにログインした後、ク ライアントに telnet してみるなど) を確認してください。 _X11TransSocketINETConnect: Can't connect: errno = 111 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 エラー 111 は "Connection refused" です。接続しようとしているサーバマ シンには到達しますが、指定したサーバがありません。ホスト名とディスプレ イ番号を正しく使っているか確認してください。 Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0 クライアントはサーバに接続を作れましたが、サーバは (認証されていない) クライアントがディスプレイを使うことを許しません。正しいマジッククッキ ーをクライアントに転送し、その期限が切れていないか (新しいセッションを 開始する時、サーバは新しいクッキーを使います) 確認してください。 10. 日本語訳について 日本語訳は Linux Japanese FAQ Project が行いました。翻訳に関するご意見 は JF プロジェクト 宛に連絡してください。 改訂履歴を以下に示します。 v0.3.1 翻訳: Tetsu Isaji Kerberosについて： うえやま るいさん 、 岡本 一幸さん 、 Jun Kuwamuraさん v0.6.3 翻訳: 野本浩一 校正： 藤原 輝嘉さん 、 加藤 大典さん 、 高城 正平さん 、 Toshimi Horie さん 、 武井 伸光さん 、 中谷 千絵さん 、 中野 武雄さん 、 森本 淳さん 、 Hiro YAMAZAKI さん 、 Tsutomu Kawashima さん 、 後藤 雅晴さん 、 佐野 武俊さん 、 岡本 一幸さん