<!doctype linuxdoctr system>

<article>

<title> Remote X Apps mini-HOWTO </title>

<author><htmlurl url="http://www.xs4all.nl/&tilde;zweije/"
    name="Vincent Zweije"> (<tt>zweije@xs4all.nl</tt>)

<date>11 July 2000

<trans>The Linux Japanese FAQ Project (<tt>JF@linux.or.jp</tt>)
<tdate>v0.6.3j1, 29 March 2001

<abstract>
<!--
This mini-HOWTO describes how to run remote X applications.  That is, how
to have an X program display on a different computer than the one it's
running on.  Or conversely: how to make an X program run on a different
computer than the one you're sitting at.  The focus of this mini-HOWTO
is on security.  This mini-HOWTO also contains information on running
X applications locally, but with a different user-id.
-->
この mini-HOWTO はリモート X アプリケーションを実行する方法について
説明します。つまり、X のプログラムを実行しているコンピュータとは
異なるところに表示をさせる方法です。逆にいいますと、X のプログラムを
あなたが対面しているコンピュータではないところで実行させる方法、となります。
この mini-HOWTO の焦点はセキュリティです。さらに X アプリケーションを
ローカルで、ただし異なったユーザ ID で、実行させる情報も含んでいます。
</abstract>

<toc>

<!--
<sect> Introduction
-->
<sect> はじめに

<p>
<!--
This mini-HOWTO is a guide how to do remote X applications.  It was
written for several reasons.
<enum>
<item> Many questions have appeared on usenet on how to run a remote
    X application.
<item> I see many, many hints of ``use <tt/xhost +hostname/'' or even
    ``<tt/xhost +/'' to allow X connections. <bf/This is ridiculously
    insecure/, and there are better methods.
<item> I do not know of a simple document that describes the options you
    <em/do/ have. Please inform me <htmlurl url="mailto:zweije@xs4all.nl"
    name="zweije@xs4all.nl"> if you know more.
</enum>
-->
この mini-HOWTO はリモート X アプリケーションを扱うためのガイドです。これを
書いた理由はたくさんあります。
<enum>
<item> 「リモート X アプリケーションを実行するには？」という質問が usenet で
多い。
<item> X 接続の許可に「<tt/xhost +hostname/ を使え」とか、ひどいのになると
「<tt/xhost +/ を使え」というようなアドバイスをうんざりするほど
目にする。xhost は途方もないセキュリティ上の問題があり、もっとよい方法がある。
<item> xhost 以外のもっとよい方法を記述した簡単な文書を知らない。
もし、他の簡単な文書を知っているなら著者 <tt>zweije@xs4all.nl</tt>
 に教えてください。
</enum>

<!--
This document has been written with unix-like systems in mind. If either
your local or remote operating system are of another flavour, you may
find here how things work. However, you will have to translate examples
yourself to apply to your own system(s).
-->
このドキュメントは UNIX ライクなシステムを対象に書かれています。ローカル
かリモートのどちらかのオペレーティングシステムが UNIX 系でなくても、
この文書で動作の仕組みを見つけられるかもしれません。しかしながら、例として
書いたことは各自のシステムに合わせて変更しなければならないでしょう。

<!--
The most recent version of this document is always available on
WWW at <htmlurl url="http://www.xs4all.nl/~zweije/xauth.html"
name="http://www.xs4all.nl/&tilde;zweije/xauth.html">. It
is also available as the Linux Remote X Apps mini-HOWTO at
<htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps"
name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps">. Linux
(mini-)HOWTOs are available by http or ftp from <htmlurl
url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html"
name="sunsite.unc.edu">.
-->
このドキュメントの最新版は
 <htmlurl url="http://www.xs4all.nl/&tilde;zweije/xauth.html"
 name="http://www.xs4all.nl/&tilde;zweije/xauth.html">
 で入手できます。また「Remote X Apps mini-HOWTO」として
 <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps"
 name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps">
 で入手できます。Linux (mini-)HOWTO は
 <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html"
 name="sunsite.unc.edu">
 から http か ftp で入手できます。

<!--
This is version 0.6.3. No guarantees, only good intentions. I'm open
to suggestions, ideas, additions, useful pointers, (typo) corrections,
etc... I want this to remain a simple readable document, though, in the
best-meant HOWTO style. Flames to <tt>/dev/null</tt>.
-->
このバージョンは 0.6.3 です。善意により公開されており、無保証です。提案、
アイディア、追加、役立つポインタ、(打ち間違い等の)訂正などを募集しています。
でも、この文書は簡単で読み易い文書に保っておきたいと思っています。
最もよい意味での HOWTO 形式ですね。いちゃもんは /dev/null へ。

<!--
Contents last updated on 11 July 2000 by <htmlurl
url="http://www.xs4all.nl/~zweije/index.html" name="Vincent Zweije">
-->
内容の最終更新は 2000年06月11日 に
 <htmlurl url="http://www.xs4all.nl/&tilde;zweije/index.html"
 name="Vincent Zweije">
 が行いました。

<!--
<sect> Related Reading
-->
<sect> 関連した読み物

<p>
<!--
A related document on WWW is ``What to do when Tk says that your display
is insecure'', <htmlurl url="http://ce-toolkit.crd.ge.com/tkxauth/"
name="http://ce-toolkit.crd.ge.com/tkxauth/">. It was written by <htmlurl
url="http://ce-toolkit.crd.ge.com/people/kennykb.html" name="Kevin
Kenny">. It suggests a similar solution to X authentication to that in
this document (xauth). However, Kevin aims more at using xdm to steer
xauth for you.
-->
&dquot;What to do when Tk says that your display is insecure&dquot; という
関連ドキュメントが WWW 上の
 <htmlurl url="http://ce-toolkit.crd.ge.com/tkxauth/"
 name="http://ce-toolkit.crd.ge.com/tkxauth/">
(<htmlurl url="http://www.linux.or.jp/JF/JFdocs/tkxauth.html" name="日本語訳">)
 にあります。
<htmlurl url="http://ce-toolkit.crd.ge.com/people/kennykb.html"
 name="Kevin Kenny">
 氏によって書かれたものです。このドキュメント (xauth) では X 認証について
この文書と同じような解決方法を提案しています。しかし Kevin は
 xauth の制御に xdm を用いることの方を中心にしているようです。

<!--
The X System Window System Vol. 8 X ``Window System Administrator's
Guide'' from <htmlurl url="http://www.ora.com/" name="O'Reilly and
Associates"> has also been brought to my attention as a good source of
information. Unfortunately, I've not been able to check it out.
-->
<htmlurl url="http://www.ora.com/" name="O'Reilly and Associates"> の
 The X System Window System Vol. 8 X &dquot;Window System Administrator's
 Guide&dquot; もまたよい情報源なので注意を惹かれます。あいにく著者はチェック
できていません。

<!--
Yet another document much like the one you're reading
now, titled ``Securing X Windows'', is available at <htmlurl
url="http://ciac.llnl.gov/ciac/documents/ciac2316.html"
name="http://ciac.llnl.gov/ciac/documents/ciac2316.html">.
-->
さらにもう一つのドキュメントは &dquot;Securing X Windows&dquot; という
タイトルですぐにでも読めるものです。
<htmlurl url="http://ciac.llnl.gov/ciac/documents/ciac2316.html"
 name="http://ciac.llnl.gov/ciac/documents/ciac2316.html">
 から入手できます。

<!--
Also check out usenet newsgroups, such as <tt/comp.windows.x/,
<tt/comp.os.linux.x/, and <tt/comp.os.linux.networking/.
-->
<tt/comp.windows.x/、<tt/comp.os.linux.x/ や <tt/comp.os.linux.networking/ の
 usenet ニュースグループもチェックしてください。

<!--
<sect> The Scene
-->
<sect> 想定する状況

<p>
<!--
You're using two computers. You're using the X window system of the first
to type to and look at. You're using the second to do some important
graphical work. You want the second to show its output on the display
of the first. The X window system makes this possible.
-->
２台のコンピュータを使っています。１台目で、入力と表示のために
 X ウィンドウシステムを使っています。２台目をいくつかの重要なグラフィックの
仕事に使っています。１台目のディスプレイに２台目の出力を表示させたい。
X ウィンドウシステムはこれができます。

<!--
Of course, you need a network connection for this. Preferably a fast
one; the X protocol is a network hog. But with a little patience
and suitable protocol compression, you can even run applications
over a modem. For X protocol compression, you might want to check
out dxpc <htmlurl url="http://www.vigor.nu/dxpc/"
name="http://www.vigor.nu/dxpc/"> or LBX
<url url="http://www.paulandlesley.org/faqs/LBX-HOWTO.html"
name="http://www.paulandlesley.org/faqs/LBX-HOWTO.html"> (also
known as the <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/LBX"
name="LBX mini-HOWTO">).
-->
もちろんネットワーク接続が必要です。X プロトコルはネットワークを大食いする
ので、なるべく速いものが必要です。ですがちょっとの我慢と適切なプロトコル圧縮を
使えば、モデム経由でアプリケーションを実行することもできます。
X プロトコル圧縮については dxpc
 <htmlurl url="http://www.vigor.nu/dxpc/" name="http://www.vigor.nu/dxpc/">
 か LBX
 <url url="http://www.paulandlesley.org/faqs/LBX-HOWTO.html"
 name="http://www.paulandlesley.org/faqs/LBX-HOWTO.html"> 
(またの名を <htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/mini/LBX"
 name="LBX mini-HOWTO"> という) をチェックしてください。

<!--
You must do two things to achieve all this:

<enum>

<item> Tell the local display (the server) to accept connections from
    the remote computer.

<item> Tell the remote application (the client) to direct its output to
    your local display.

</enum>
-->
１台目のディスプレイに２台目の出力を表示するには、以下の２つのことを
しなければなりません。
<enum>
<item> リモートコンピュータからの接続を受け付けるよう、ローカルディスプレイ
 (サーバ) に指定する。
<item> ローカルディスプレイにその出力を行うよう、リモートアプリケーション
 (クライアント) に指定する。
</enum>

<!--
<sect> A Little Theory
-->
<sect> ちょっとした理論

<p>
<!--
The magic word is <tt/DISPLAY/. In the X window system, a display consists
(simplified) of a keyboard, a mouse and a screen. A display is managed
by a server program, known as an X server. The server serves displaying
capabilities to other programs that connect to it.
-->
マジックワードは <tt/DISPLAY/ です。X ウィンドウシステムでは、ディスプレイは
 (単純化して) キーボード、マウス、スクリーンから成ります。
ディスプレイはサーバプログラムによって管理されます。
これは X サーバと呼びならわされています。
このサーバは、サーバに接続する他のプログラムに表示能力を与えます。

<!--
A display is indicated with a name, for instance:
-->
ディスプレイは名前で表されます。例えば：

<itemize>

<item> <tt/DISPLAY=light.uni.verse:0/

<item> <tt/DISPLAY=localhost:4/

<item> <tt/DISPLAY=:0/

</itemize>

<!--
The display consists of a hostname (such as <tt/light.uni.verse/ and
<tt/localhost/), a colon (<tt/:/), and a sequence number (such as <tt/0/
and <tt/4/). The hostname of the display is the name of the computer
where the X server runs. An omitted hostname means the local host. The
sequence number is usually 0 &#045;&#045; it can be varied if there are multiple
displays connected to one computer.
-->
ディスプレイの表記はホスト名 (例示した light.uni.verse や localhost)、
コロン(:)、番号 (例示した 0 や 4 ) から成ります。ディスプレイの表記の
ホスト名は X サーバを実行しているコンピュータの名前です。ホスト名を省略すると、
ローカルホストを示すことになります。
番号は普通 0 です――１台のコンピュータに複数のディスプレイが接続されて
いるのなら、別の値になるかもしれません。

<!--
If you ever come across a display indication with an extra <tt/.n/
attached to it, that's the screen number. A display can actually have
multiple screens. Usually there's only one screen though, with number
<tt/n=0/, so that's the default.
-->
上記のディスプレイ表記に <tt/.n/ が添えられることもあります。この <tt/.n/ は
スクリーン番号を指しています。ディスプレイは複数のスクリーンを持つことが
できます。普通は (番号 <tt/n=0/ の) ひとつのスクリーンしかないので、
これが既定値になっています。

<!--
Other forms of <tt/DISPLAY/ exist, but the above will do for our purposes.
-->
他の <tt/DISPLAY/ の書式もありますが、上記の書式で本書の目的を行うには
十分です。

<!--
For the technically curious:
<itemize>

<item> <tt/hostname:D.S/ means screen <tt/S/ on display <tt/D/ of host
       <tt/hostname/; the X server for this display is listening at TCP
       port <tt/6000+D/.

<item> <tt>host/unix:D.S</tt> means screen <tt/S/ on display <tt/D/
       of host <tt/host/; the X server for this display is listening
       at UNIX domain socket <tt>/tmp/.X11-unix/XD</tt> (so it's only
       reachable from <tt/host/).

<item> <tt/:D.S/ is equivalent to <tt>host/unix:D.S</tt>, where <tt/host/
       is the local hostname.

</itemize>
-->
技術的な興味のために：
<itemize>
<item> <tt/hostname:D.S/ はホスト <tt/hostname/　のディスプレイ番号 <tt/D/ の
スクリーン番号 <tt/S/ を意味します――この表記のディスプレイのための
 X サーバは TCP ポート <tt/6000+D/ をリッスンします。
<item> <tt>host/unix:D.S</tt> はホスト <tt/host/ のディスプレイ番号 <tt/D/ の
スクリーン番号 <tt/S/ を意味します――この表記のディスプレイのための
 X サーバは UNIX ドメインソケット <tt>/tmp/.X11-unix/XD</tt> をリッスン
します (なので <tt/host/ からしか到達できません)。
<item> <tt/:D.S/ は <tt>host/unix:D.S</tt> と等価です。ここで
 <tt/host/ はローカルのホスト名です。
</itemize>

<!--
<sect> Telling the Client
-->
<sect> クライアントに指定する<label id="tell_client">

<p>
<!--
The client program (for instance, your graphics application) knows
which display to connect to by inspecting the <tt/DISPLAY/ environment
variable. This setting can be overridden, though, by giving the client
the command line argument <tt/-display hostname:0/ when it's started. Some
examples may clarify things.
-->
クライアントプログラム (例としてグラフィックアプリケーション) は
 <tt/DISPLAY/ 環境変数を調べて接続するディスプレイを知ります。しかし、
クライアント起動時のコマンドライン引数に <tt/-display hostname:0/
 を与えた場合は、
この設定を優先します。いくつかの例で明らかにしましょう。

<!--
Our computer is known to the outside as light, and we're in domain
uni.verse. If we're running a normal X server, the display is known as
<tt/light.uni.verse:0/. We want to run the drawing program xfig on a remote
computer, called <tt/dark.matt.er/, and display its output here on light.
-->
私たちのコンピュータは外部からホスト名 light として見えており、
ドメイン uni.verse に所属しているとします。
普通に X サーバを実行しているなら、ディスプレイは
 <tt/light.uni.verse:0/ として識別されます。
<tt/dark.matt.er/ というリモートコンピュータで描画プログラムの xfig を実行し、
ローカルマシン light に xfig の出力を表示させたいと思います。

<!--
Suppose you have already telnetted into the remote computer,
<tt/dark.matt.er/.
-->
すでにリモートコンピュータ <tt/dark.matt.er/ に telnet していると想定します。

<!--
If you have csh running on the remote computer:
-->
リモートコンピュータで csh を使っているなら

<tscreen><verb>
dark% setenv DISPLAY light.uni.verse:0
dark% xfig &
</verb></tscreen>

<!--
or alternatively:
-->
とするか、あるいは

<tscreen><verb>
dark% xfig -display light.uni.verse:0 &
</verb></tscreen>

<!--
-->
とします。

<!--
If you have sh running on the remote computer:
-->
リモートコンピュータで sh を使っているなら

<tscreen><verb>
dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &
</verb></tscreen>

<!--
or, alternatively:
-->
とするか、あるいは

<tscreen><verb>
dark$ DISPLAY=light.uni.verse:0 xfig &
</verb></tscreen>

<!--
or, of course, also:
-->
とします。もちろん

<tscreen><verb>
dark$ xfig -display light.uni.verse:0 &
</verb></tscreen>

でもいいです。
<p>
(訳注；
<tscreen><verb>
dark$ env DISPLAY=light.uni.verse:0 xfig&
</verb></tscreen>
なら csh でも sh でも使えますね :) )

<!--
It seems that some versions of telnet automatically transport the
<tt/DISPLAY/ variable to the remote host. If you have one of those,
you're lucky, and you don't have to set it by hand. If not, most versions
of telnet do transport the <tt/TERM/ environment variable; with some
judicious hacking it is possible to piggyback the <tt/DISPLAY/ variable
on to the <tt/TERM/ variable.
-->
telnet の種類によっては、自動的にリモートホストへ <tt/DISPLAY/ 変数を
転送するものもあるようです。そんな telnet を使用するなら、
ディスプレイの指定を手動で行なわなくてもよいので、幸運でしょう。
telnet の殆どは <tt/TERM/ 環境変数を転送する種類なので
賢くやるなら、<tt/TERM/ 環境変数に <tt/DISPLAY/ 変数の内容を代入して
代用させることです。

<!--
The idea with piggybacking is that you do some scripting to achieve
the following: before telnetting, attach the value of <tt/DISPLAY/
to <tt/TERM/.  Then telnet out.  At the remote end, in the applicable
<tt/.*shrc/ file, read the value of <tt/DISPLAY/ from <tt/TERM/.
-->
代用するのと同様の考え方で、次のような数行のスクリプトで実現できます。
<quote>
telnet する前に、<tt/TERM/ に <tt/DISPLAY/ の値を加える。telnet する。
リモートコンピュータの適切な <tt/.*shrc/ ファイルで、<tt/TERM/ から 
<tt/DISPLAY/ の値を読む。
</quote>

<!--
<sect> Telling the Server
-->
<sect> サーバに指定する

<p>
<!--
The server will not accept connections from just anywhere. You don't want
everyone to be able to display windows on your screen. Or read what you
type &#45;&#45; remember that your keyboard is part of your display!
-->
サーバはどこからの接続でも受け付けるわけではありません。あなたのスクリーンに
すべての人がウィンドウを表示できるなんて、嬉しくないですよね。
あなたの入力を読まれたくもないでしょう――キーボードはディスプレイの
一部であるということを忘れないで下さい。

<!--
Too few people seem to realise that allowing access to your display poses
a security risk. Someone with access to your display can read and write
your screens, read your keystrokes, and read your mouse actions.
-->
ディスプレイへのアクセス許可が、セキュリティリスクの原因になる
ことを理解している人はほとんどいません。あなたのディスプレイに
アクセスできる人は、スクリーンを読み書きでき、あなたのキーストロークを
読むことやマウスの動きを読むこともできます。

<!--
Most servers know two ways of authenticating connections to it: the
host list mechanism (xhost) and the magic cookie mechanism (xauth).
Then there is ssh, the secure shell, that can forward X connections.
-->
ほとんどのサーバは接続の認証方法が２つあります――host リスト機構 (xhost) と
マジッククッキー機構 (xauth) です。また ssh(secure shell) は X 接続を転送する
ことができます。

<sect1> xhost

<p>
<!--
Xhost allows access based on hostnames. The server maintains a list
of hosts which are allowed to connect to it. It can also disable host
checking entirely. Beware: this means no checks are done, so <em/every/
host may connect!
-->
xhost は host 名にもとづいてアクセスを許します。サーバは、接続を許された
 host のリストを管理します。host のチェックを完全に無効にすることもできます。
注意してください――無効にするとチェックをしなくなるので全ての host が
接続できます！

<!--
You can control the server's host list with the xhost program. To use
this mechanism in the previous example, do:
-->
xhost プログラムを用いるとサーバの host リストを制御できます。
前述の例でこの機構を使うには

<tscreen><verb>
light$ xhost +dark.matt.er
</verb></tscreen>

<!--
-->
とします。

<!--
This allows all connections from host <tt/dark.matt.er/. As soon as
your X client has made its connection and displays a window, for safety,
revoke permissions for more connections with:
-->
これはホスト dark.matt.er からの接続をすべて許します。X クライアントが接続され
ウィンドウが表示されたら、すぐに安全のため接続許可を取り消します。それには

<tscreen><verb>
light$ xhost -dark.matt.er
</verb></tscreen>

<!--
-->
とします。

<!--
You can disable host checking with:
-->
host のチェックを無効にするには

<tscreen><verb>
light$ xhost +
</verb></tscreen>

<!--
-->
とします。

<!--
This disables host access checking and thus allows <em/everyone/
to connect. You should <em/never/ do this on a network on which you
don't trust <em/all/ users (such as Internet). You can re-enable host
checking with:
-->
これは host のアクセスチェックを無効にしているので、すべての人に接続を
許しています。信用できないユーザーがいるネットワーク (例えばインターネット)
 上では決してアクセスチェックを無効にしないでください。host のチェックを
再度有効にするには

<tscreen><verb>
light$ xhost -
</verb></tscreen>

<!--
-->
でできます。

<!--
xhost - by itself does <em/not/ remove all hosts from the access list
(that would be quite useless - you wouldn't be able to connect from
anywhere, not even your local host).
-->
&dquot;xhost -&dquot; は、アクセスリストから全部のホストを削除するわけでは
ありません (もしそうなら、不便極まりません――どこから
も、ローカルホストさえからも接続できなくなります)。

<!--
<em/Xhost is a very insecure mechanism./ It does not distinguish between
different users on the remote host. Also, hostnames (addresses actually)
can be spoofed. This is bad if you're on an untrusted network (for
instance already with dialup PPP access to Internet).
-->
xhost はとても危なっかしい機構です。xhost はリモートホスト上のユーザを
区別できませんし、
host 名 (実際にはアドレス) も偽ることができます。もし信用できないユーザがいる
ネットワーク (例えばインターネットにダイアルアップ PPP アクセス) にいるなら、
これは良くないことです。
<p>
(訳注：アドレスを偽れる理由。xhost において X サーバが維持するリストは数値が
登録されています。host 名を使って登録した場合でも gethostbyname 関数により
その IP アドレスが数値となります。ですので、４バイトの数値になります。
X サーバがアクセスチェックをする時に使用するのは、X クライアントが送出した
 IP パケットのソース IP アドレスを使用するのではありません。データ部に
 X クライアントが乗せた任意の数値です。X クライアントのプログラムの作りにより
何でも乗せることができます。
訳者が以前使用したことのあるメーカ製ワークステーションは、hostid の値を乗せて
いました。hostid の既定値は inittab の中で、プライマリの IP アドレスを
定義してるだけでした。この場合は、クラッキングプログラムを書かずとも、数行の
スクリプトを書くだけで、ブルドーザアタックが行えます。)

<sect1> xauth

<p>
<!--
Xauth allows access to anyone who knows the right secret. Such a secret
is called an authorization record, or a magic cookie. This authorization
scheme is formally called MIT-MAGIC-COOKIE-1.
-->
xauth は正しい機密を知っている人にアクセスを許します。そのような機密は
認証レコードあるいはマジッククッキーと呼ばれます。この認証スキームの正式な
呼称は MIT-MAGIC-COOKIE-1 です。

<!--
The cookies for different displays are stored together in
<tt>&tilde;/.Xauthority</tt>.  Your <tt>&tilde;/.Xauthority</tt> must be 
inaccessible
for group/other users.  The xauth program manages these cookies, hence
the nickname xauth for the scheme.
-->
異なるディスプレイに対するそれぞれクッキーは、<tt>&tilde;/.Xauthority</tt>
 にまとめて
格納されます。<tt>&tilde;/.Xauthority</tt> はグループユーザおよび他ユーザには
アクセスできないようにしなければなりません (訳注：<tt/chown 600 .Xauthority/
 としておきます)。xauth プログラムはこれらのクッキーを管理します。それ故に
このスキームのニックネームは xauth といいます。

<!--
On starting a session, the server reads a cookie from the file that
is indicated by the <tt/-auth/ argument. After that, the server only
allows connections from clients that know the same cookie. When the
cookie in <tt>&tilde;/.Xauthority</tt> changes, <em/the server will not pick
up the change/.
-->
セッションを始める際、サーバは <tt/-auth/ の引数で指定したファイルから
クッキーを読みます。その後サーバは同じクッキーを知るクライアントの接続のみ
許します。接続が確立された後で <tt>&tilde;/.Xauthority</tt> のクッキーが
変更されてもサーバはこの変更を取り出しません。

<!--
Newer servers can generate cookies on the fly for clients that ask for
it. Cookies are still kept inside the server though; they don't end up
in <tt>&tilde;/.Xauthority</tt> unless a client puts them there. According to
David Wiggins:
-->
最近のサーバは照会したクライアント用のクッキーをすぐに作ることができます。
しかし、クッキーはサーバ内に保存されたままです――クライアントが
 <tt>&tilde;/.Xauthority</tt> にクッキーを追加しない限り
 <tt>&tilde;/.Xauthority</tt> には入りません。David Wiggins氏によると

<quote>
<!--
A further wrinkle was added in X11R6.3 that you may be interested in. Via
the new SECURITY extension, the X server itself can generate and return
new cookies on the fly. Furthermore, the cookies can be designated
``untrusted'' so that applications making connections with such cookies
will be restricted in their operation. For example, they won't be able
to steal keyboard/mouse input, or window contents, from other trusted
clients. There is a new ``generate'' subcommand to xauth to make this
facility at least possible to use, if not easy.
-->
あなたが興味を示すような名案が X11R6.3 で追加されました。
新しいセキュリティ拡張を通して、X サーバはすぐに新しいクッキーを
作って返すことができます。さらにクッキーを「信用しない」ように指定できるので、
そのようなクッキーで接続を行ったアプリケーションは次のように操作を制限され
ます。例えば他の信用できるクライアントのキーボード/マウスの入力やウィンドウに
表示されている内容を盗めなくなります。簡単でないにしても、少なくともこの機能を
使うことができる新しいサブコマンド 
&dquot;generate&dquot; が xauth にあります。
</quote>

<!--
Xauth has a clear security advantage over xhost. You can limit access to
specific users on specific computers. It does not suffer from spoofed
addresses as xhost does. And if you want to, you can still use xhost
next to it to allow connections.
-->
xauth は xhost に比べてセキュリティに優れています。また特定のコンピュータの
特定のユーザだけにアクセスを制限することができます。xhost のように偽った
アドレスからの接続はできません。必要なら xauth の後で接続を許すために xhost を
使うこともできます。

<!--
<sect2> Making the Cookie
-->
<sect2> クッキーを作る

<p>
<!--
If you want to use xauth, you must start the X server with the <tt/-auth
authfile/ argument. If you use the startx script, that's the right place
to do it. Create the authorization record as below in your startx script.
-->
xauth を使いたいのなら、<tt/-auth authfile/ 引数を付けて、X サーバを起動
しなければなりません (訳注：authfile は認証ファイルを指す PATH)。
startx スクリプトを使うのなら、xinit の右側に記述します。以下のようにして
startx スクリプトの中で認証レコードを作成します。

<!--
Excerpt from <tt>/usr/X11R6/bin/startx</tt>:
-->
<tt>/usr/X11R6/bin/startx</tt>からの引用：

<tscreen><verb>
mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
</verb></tscreen>

<!--
Mcookie is a tiny program in the util-linux package,
primary site <htmlurl url="ftp://ftp.math.uio.no/pub/linux/"
name="ftp://ftp.math.uio.no/pub/linux/">.  Alternatively, you
can use md5sum to massage some random data (from, for instance,
<tt>/dev/urandom</tt> or <tt/ps -axl/) into cookie format:
-->
mcookie は util-linux パッケージにある小さなプログラムで、
<htmlurl url="ftp://ftp.math.uio.no/pub/linux/"
 name="ftp://ftp.math.uio.no/pub/linux/">
 から入手できます。あるいは、 md5sum を用いて
無作為データ (例えば <tt>/dev/urandom</tt> や <tt/ps -axl/) を
クッキー形式に変換 (massage) することもできます。

<tscreen><verb>
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
</verb></tscreen>

<!--
If you can't edit the startx script (because you aren't root), get
your system administrator to set up startx properly, or let him set up
xdm instead. If he can't or won't, you can make a <tt>&tilde;/.xserverrc</tt>
script.  If you have this script, it is run by xinit instead of the real
X server. Then you can start the real X server from this script with the
proper arguments. To do so, have your <tt>&tilde;/.xserverrc</tt> use the magic
cookie line above to create a cookie and then exec the real X server:
-->
root になれず startx スクリプトを編集できないのなら、システム管理者に
 statx スクリプトを適切に設定してもらうか、あるいは xdm を設定して
もらってください。管理者ができないもしくはしないなら、
<tt>&tilde;/.xserverrc</tt> スクリプトで実現できます。このスクリプトがあると、
xinit は実際の X サーバの代わりにこのファイルを実行します。
したがって、このスクリプトから実際の X サーバを適切な引数で起動できます。
こうするには、
 <tt>&tilde;/.xserverrc</tt> に上記のマジッククッキーの行を書いて
クッキーを作らせ、次いで X サーバを起動する行を書きます。

<tscreen><verb>
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
</verb></tscreen>

<!--
If you use xdm to manage your X sessions, you can use
xauth easily.  Define the DisplayManager.authDir resource in
<tt>/etc/X11/xdm/xdm-config</tt>.  Xdm will pass the <tt/-auth/ argument
to the X server when it starts.  When you then log in under xdm, xdm
puts the cookie in your <tt>&tilde;/.Xauthority</tt> for you.  See xdm(1)
for more information. For instance, my <tt>/etc/X11/xdm/xdm-config</tt>
has the following line in it:
-->
X セッションの管理に xdm を使うなら、xauth を簡単に使用できます。
<tt>/etc/X11/xdm/xdm-config</tt> の中に DisplayManager.authDir リソースを
定義してください。xdm は X サーバが起動する時に -auth 引数を渡すように
なります。xdm のもとでログインした時、xdm は <tt>&tilde;/.Xauthority</tt> に
クッキーを置きます。詳しくは xdm(1) の man ページを参照して下さい。例えば
著者の <tt>/etc/X11/xdm/xdm-config</tt> では以下の行が書かれています。

<tscreen><verb>
DisplayManager.authDir: /var/lib/xdm
</verb></tscreen>

<!--
<sect2> Transporting the Cookie
-->
<sect2> クッキーの転送

<p>
<!--
Now that you have started your X session on the server host
<tt/light.uni.verse/ and have your cookie in <tt>&tilde;/.Xauthority</tt>, you
will have to transfer the cookie to the client host, <tt/dark.matt.er/.  There 
are several ways to do this.
-->
サーバホスト <tt/light.uni.verse/ で X セッションを開始し、
<tt>&tilde;/.Xauthority</tt> の中にクッキーを持ちました。
次はクライアントホスト <tt/dark.matt.er/ へクッキーを転送する必要があります。
これには、たくさんの方法があります。

<!--
<sect3> Shared Home Directories
-->
<sect3> ホームディレクトリの共有

<p>
<!--
The easiest is when your home directories on light and dark are
shared. The <tt>&tilde;/.Xauthority</tt> files are the same, so the
cookie is transported instantaneously.  However, there's a catch: when
you put a cookie for <tt/:0/ in <tt>&tilde;/.Xauthority</tt>, dark will
think it's a cookie for itself instead of for light.  You must use an
explicit host name when you create the cookie; you can't leave it out.
You can install the same cookie for both <tt/:0/ and <tt/light:0/ with
this little piece of sed wizardry:
-->
light と dark 上のあなたのホームディレクトリが共有されていれば
一番簡単です。両方の <tt>&tilde;/.Xauthority</tt> ファイルは同じなので、即座に
クッキーは転送されます。
しかし落とし穴があります――<tt>&tilde;/.Xauthority</tt> に <tt/:0/ のための
クッキーを置いた時、dark は light のためのクッキーと考えずに自身のための
クッキーだと考えます。クッキーを作る時、明示的なホスト名を使う
べきです――これを省略することはできません。
次のような、ちょっとした sed の技を使えば、<tt/:0/ と <tt/light:0/ の両方の
ために同じクッキーを置くことができます。

<tscreen><verb>
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /' -e p -e "s/:/$HOST&/"|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
</verb></tscreen>

<!--
<sect3> By the Remote Shell, <tt/rsh/
-->
<sect3> リモートシェル <tt/rsh/ を使う

<p>
<!--
If the home directories aren't shared, you can transport the cookie by
means of rsh, the remote shell:
-->
ホームディレクトリが共有されていないのなら、リモートシェル rsh による方法で
クッキーを転送できます。

<tscreen><verb>
light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -
</verb></tscreen>

<!--
-->
とします。これは

<!--
<enum>

<item> Extract the cookie from your local <tt>&tilde;/.Xauthority</tt>
(<tt/xauth nlist :0/).

<item> Transfer it to dark.matt.er (<tt/| rsh dark.matt.er/).

<item> Put it in the <tt>&tilde;/.Xauthority</tt> there (<tt/xauth nmerge -/).

</enum>
-->
<enum>
<item> ローカルの <tt>&tilde;/.Xauthority</tt> からクッキーを抽出する 
 (xauth nlist :0)。
<item> dark.matt.er に転送する (| rsh dark.matt.er)。
<item> 転送先の <tt>&tilde;/.Xauthority</tt> に置く (xauth nmerge -)。
</enum>

<!--
-->
を行います。

<p>
<!--
Notice the use of <tt/${HOST}/.  You need to transport the cookie that is
explicitly associated with the local host.  A remote X application would
interpret a display value of <tt/:0/ as referring to the remote machine,
which is not what you want!
-->
<tt/${HOST}/ の使い方に注意してください。ローカルホストと
明示的に関連づけられたクッキーを転送する必要があります。
リモート X アプリケーションはディスプレイの値 <tt/:0/
をリモートマシンのものと解釈します。
これはやりたいこととは違うでしょう？

<!--
<sect3> Manually, by Telnet
-->
<sect3> Telnet を使い手動で行う

<p>
<!--
It's possible that rsh doesn't work for you. Besides that, rsh also has a
security drawback (spoofed host names again, if I remember correctly). If
you can't or don't want to use rsh, you can also transfer the cookie
manually, like:
-->
rsh が動作しないこともあります。また rsh はセキュリティ上の欠点もあります
 (著者の記憶が正しいなら、これも host 名を偽れます)。
rsh を使えないか使わないなら以下のように手動でクッキーを転送できます。

<tscreen><verb>
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$
</verb></tscreen>

<!--
See also rsh(1) and xauth(1x) for more information.
-->
詳しくは rsh(1)、xauth(1x) を参照して下さい。

<!--
<sect3> Automating the Telnet Way
-->
<sect3> Telnet で自動に行う方法

<p>
<!--
It may be possible to piggyback the cookie on the <tt/TERM/ or
<tt/DISPLAY/ variable when you do a telnet to the remote host.  This would
go the same way as piggybacking the <tt/DISPLAY/ variable on the <tt/TERM/
variable.  See section 5: Telling the Client.  You're on own here from
my point of view, but I'm interested if anyone can confirm or deny this.
-->
リモートホストへ telnet する時に、<tt/TERM/ か <tt/DISPLAY/ 変数に
クッキーを代入して代用させることができます。これは <tt/TERM/ 変数に
 <tt/DISPLAY/ 変数を代用させるのと同じ方法で実行できるでしょう。
セクション 5 の「<ref id="tell_client" name="クライアントに指定する">」
を参照してください。
これについては異論のある方もいらっしゃるでしょう。この方法で本当にうまく
いくのかどうか、あるいは駄目なのか、という点を知りたいので、もし実際に
検証できた人がいれば結果を著者まで送っていただけたら幸いです。
<p>
(訳注：クッキーは元々ネットワーク透過です。
しかし、X はマルチプラットフォーム環境なので、充分なテストが必要
であるということだと思われます。)

<!--
Notice, however, that environment variables can be observed by others on
some unices, and you won't be able to prevent the cookie in <tt/$TERM/
from showing up if people are looking for it.
-->
でも注意、他の UNIX では、別のユーザからでも環境変数を見ることができることも
あります。そんな場合、 <tt>&dollar;TERM</tt> の中に入れたクッキーを他人に
見えないようにするすべはありません。

<!--
<sect2> Using the Cookie
-->
<sect2> クッキーを使う

<p>
<!--
An X application on dark.matt.er, such as xfig above, will automatically
look in <tt>&tilde;/.Xauthority</tt> there for the cookie to authenticate
itself with.
-->
dark.matt.er 上の (前述の xfig のような) X アプリケーションは、
認証に使うクッキーを自動的に <tt>&tilde;/.Xauthority</tt> から読みます。

<p>
<!--
There's a little wrinkle when using <tt/localhost:D/.  X client
applications translate <tt/localhost:D/ into <tt>host/unix:D</tt> for
the purpose of cookie retrieval.  Effectively, this means that a cookie
for <tt/localhost:D/ in your <tt>~/.Xauthority</tt> has <em/no/ effect.
-->
<tt/localhost:D/ を使う時は、ちょっとした問題があります。X クライアント
アプリケーションは、クッキー検索の目的のために <tt/localhost:D/ を
 <tt>host/unix:D</tt> と解釈します。実際には、<tt>&tilde;/.Xauthority</tt> に 
 <tt/localhost:D/ のクッキーを置く方法は効果がありません。

<!--
If you think about it, it's only logical.  The interpretation of
<tt/localhost/ depends entirely on the machine on which it's interpreted.
It would give a horrible mess when you have a shared home directory,
such as through NFS, with several hosts all interfering with each
other's cookies.
-->
考えてみれば、単に論理に従っているに過ぎないことがわかるでしょう。
<tt/localhost/ の解釈は、
それを解釈するマシンに完全に左右されます。NFS などでホームディレクトリを
共有すると、たくさんのホストで各々の他のクッキーが全て干渉しあって、
ひどい状態に陥ることになるでしょう。

<sect1> SSH

<p>
<!--今まで authorization record だったのに?
Authority records are transmitted over the network with no encryption.
If you're even worried someone might snoop on your connections, use ssh,
the secure shell. It will do X forwarding over encrypted connections.  And
besides, it's great in other ways too.  It's a good structural improvement
to your system.  Just visit <htmlurl url="http://www.ssh.org/"
name="http://www.ssh.org/">, the ssh home page.
-->
認証レコードは暗号化されずにネットワークを経由して送信されます。誰かが接続を
のぞく心配があるなら、ssh(secure shell) を使ってください。これは暗号化された
接続を経由して X を転送します。それにまた、ほかにもすばらしいことがあります。
それはシステムの構造改善です。ssh ホームページ
 <htmlurl url="http://www.ssh.org/" name="http://www.ssh.org/">
 を見てください。

<!--
Who knows anything else on authentication schemes or encrypting X
connections?  Maybe kerberos?
-->
誰か認証スキームや暗号化 X 接続について他に何か知っていませんか？
kerberosかな？

<p>
<descrip>
<tag>訳注：</tag>
Kerberosについて、うえやま るいさん、岡本さんからのコメントをまとめました：
<p>
ケルベロスはギリシャ神話に出てくる冥界の支配者ハデスの飼い犬で３つの
頭をもち冥界の門を守る番犬です。"Kerberos" は MIT の "Athena" 計画の一貫
として研究開発されました。RFC 1510 が 1993 年に発行されてます。
<p>
Kerberos は信頼できないネットワークで安全な認証・通信を行うために、信頼でき
る第三者を使うシステムです。内部の暗号は 対称鍵暗号DESを使います。DESなので
あまり強くはありません。しかし、チケットという仕組で認証を行うので運用が簡単
で、安全な認証と通信ができます。鍵配布センターを階層化して、大規模なシステム
にも対応することもできるようです。
<p>
ふつうの方法だと、クライアントがサーバを利用するときは相手が本当に本物であ
るか互いに分かりません。そこで、お互いが信頼している第三者に身元保証しても
らえばよいという考えに基づいています。その第三者が鍵配布センターというもの
で、その鍵配布センターにサーバを利用するためのチケットを発行してもらいます。
だれでもチケットを発行してもらえるわけはなくクライアントとサーバの鍵を登録
しておく必要があります。
鍵配布センターに発行してもらったチケットは、クライアント(発行してもらう側) 
の鍵で暗号化されているので、これを復号できるということは、クライアントは確かに
本人であることがわかります(<em/本人じゃなければチケットを取りだせないので、
サーバを利用することはできません/)。
<p>
チケットは復号化した中に入っていて、このチケットはサーバの鍵で暗号化されて
います。そこで「サーバがチケットを復号化できる = サーバも確かに本人である」
ということになります(<em/復号化した中にセッション鍵が入っていて、それ以降の
通信でこのセッション鍵を使うのため、本人以外は続行できません/)。
<p>
この欠点は、チケットの再利用ができてしまうところです。攻撃者はチケットの内容
を見れませんが、流れているチケットを拾ってそのままもう一回サーバに送れば本人
のふりをできます。そのために、タイムスタンプを暗号化して一緒に送ります。
古いタイムスタンプ付きのチケットは使えません。それに、サーバはタイムスタンプ
を記録しているので、まったく同じスタンプを持つチケットは無効です。
<p>
システム全体での欠点は、鍵配布センターが存在することです。
鍵すべてを登録しているので、ここを破られると安全もなにもありません。
<p>
XFree86 のマニュアルの翻訳(岡本さん)が JF にあります。
X の認証関係の参考にしてください。また、国内では OPEN DESIGN No.14 CQ 出版社 
<tt/ISBN4-7898-1806-3 C3055 &bsol;1748E/の
「集中特集最新の暗号によるセキュリティの実現」が参考になります。
<p>
ポインタ：
<p>FreeBSDハンドブックのページ：<htmlurl
 url="http://www.freebsd.org/ja_JP.EUC/handbook/handbook64.html#66"
 name="http://www.freebsd.org/ja_JP.EUC/handbook/handbook64.html#66">
<p><htmlurl
 url="http://www.releenet.co.jp/bsd/handbook/handbook60.html"
 name="http://www.releenet.co.jp/bsd/handbook/handbook60.html">
<p>Jun Kuwamuraさんのページ：<htmlurl
 url="http://stealth.rccm.co.jp/&tilde;juk/krb/"
 name="http://stealth.rccm.co.jp/&tilde;juk/krb/">
</descrip>

<!--
<sect> X Applications from Another User-id
-->
<sect> 別のユーザ ID からの X アプリケーション

<p>
<!--
Suppose you want to run a graphical configuration tool that requires
root privileges.  However, your X session is running under your usual
account.  It may seem strange at first, but the X server will <em/not/
allow the tool to access your display.  How is this possible when root
can normally do anything?  And how do you work around this problem?
-->
root 特権の必要な、グラフィカルな設定ツールを実行したいとしましょう。しかし、
X セッションは普通のアカウントで実行しています。始めは奇妙に思うかも
しれませんが、X サーバはツールがディスプレイにアクセスすることを許しません。
root で普通に何かしたい時に、どうすれば可能ですか？
そしてどうすればこの問題を回避できますか？

<p>
<!--
Let's generalise to the situation where you want to an X appliation
under a user-id <tt/clientuser/, but the X session was started
by <tt/serveruser/.  If you have read the section on cookies,
it is clear why <tt/clientuser/ cannot access your display:
<tt>~clientuser/.Xauthority</tt> does not contain the right magic
cookie for accessing the display.  The right cookie is found in
<tt>~serveruser/.Xauthority</tt>.
-->
ユーザ ID <tt/clientuser/ で X アプリケーションを起動したいが X セッションは
<tt/serveruser/ で起動されているという、一般的な状況にしましょう。クッキーの
セクションを読んでいれば、なぜ <tt/clientuser/ がディスプレイに
アクセスできないのか分かるはずです。
<quote>
<tt>&tilde;clientuser/.Xauthority</tt> はディスプレイにアクセスするための
正しいマジッククッキーを含んでいません。正しいクッキーは
 <tt>&tilde;serveruser/.Xauthority</tt> にあります。
</quote>

<!--
<sect1> Different Users on the Same Host
-->
<sect1> 同一ホスト上の異なるユーザ

<p>
<!--
Of course, anything that works for remote X also works for X from
a different user-id as well (particularly <tt/slogin localhost -l
clientuser/).  It's just that the client host and the server host happen
to be the same.  However, when both hosts are the same, there are some
shortcuts for transferring the magic cookie.
-->
もちろん、リモート X で動作するものは、異なるユーザ ID の X でも同じように
動作します (端的には <tt/slogin localhost -l clientuser/)。
クライアントホストとサーバホストがたまたま同じだというだけです。しかし、
両方のホストが同じ時、マジッククッキーの転送には近道があります。

<p>
<!--
We'll assume that you use <tt/su/ to switch user-ids.  Basically, what
you have to do is write a script that will call <tt/su/, but wraps the
command that <tt/su/ executes with some code that does the necessary
things for remote X.  These necessary things are setting the <tt/DISPLAY/
variable and transferring the magic cookie.
-->
ユーザ ID の切り替えに <tt/su/ を使うと仮定します。
基本的に、行わなければならないことは、<tt/su/ を呼ぶスクリプトを書き、
そこで <tt/su/ の行うコマンドを、リモート X に必要な処理を行う
適切なコードでラップすることです。
必要な処理とは
 <tt/DISPLAY/ 変数の設定とマジッククッキーの転送です。

<p>
<!--
Setting <tt/DISPLAY/ is relatively easy; it just means defining
<tt/DISPLAY="$DISPLAY"/ before running the su command argument.  So you
could just do:
-->
<tt/DISPLAY/ の設定は比較的簡単です――su コマンドを実行する前に、
その引数として <tt/DISPLAY="$DISPLAY"/ を定義するだけです。
以下のようにします。

<tscreen><verb>
su - clientuser -c "env DISPLAY=$DISPLAY clientprogram &"
</verb></tscreen>

<p>
<!--
This doesn't work yet, because we still have to transfer the cookie.
We can retrieve the cookie using <tt/xauth list "$DISPLAY"/.  This command
happens to list the cookie in a format that's suitable for feeding back
to the <tt/xauth add/ command; just what we need!
-->
これだけでは動作しません。さらにクッキーの転送を行う必要があります。
クッキーの取得は <tt/xauth list "$DISPLAY"/ を使えば可能です。
このコマンドがクッキーのリストに用いる書式は、たまたま
 <tt/xauth add/ コマンドに与える際の書式に合致しています
――ちょうど必要としていたものです。

<!--
We shall want to pass the cookie through a pipe.  Unfortunately, it
isn't easy to pass something through a pipe to the <tt/su/ command,
because <tt/su/ wants to read the password from its standard input.
Fortunately again, in a shell script we can joggle some file descriptors
around, and get it done.
-->
当然パイプでクッキーを渡したいところです。残念ながら、<tt/su/ は
その標準入力からパスワードを読もうとするので、<tt/su/ コマンドにパイプで渡す
ことは簡単ではありません。ここでも都合のいいことには、
シェルスクリプトの内部では
ファイル記述子をいじり回すことができますので、これが可能になります。

<!--
So we write a script around this, parameterizing by <tt/clientuser/
and <tt/clientprogram/.  Let's improve the script a little while we're
at it, making it less readable but more robust.  It looks like this:
-->
<tt/clientuser/ と <tt/clientprogram/ をパラメータ化し汎用化したスクリプトを
書きます。読みやすさは少し犠牲にして頑強になるように、スクリプトを改善
しましょう。以下のようになります。

<tscreen><verb>
#!/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>&-"

}
</verb></tscreen>

<!--
I think this is portable and works well enough in most circumstances.
The only shortcoming I can think of right now is that, due to using
<tt/'$*'/, single quotes in <tt/command/ will mess up quoting in the
<tt/su/ command argument (<tt/'$*'/).  If there's anything else seriously
wrong with it, please drop me an email.
-->
ほとんどの状況で、移植性と動作に十分だと考えます。
現在著者が考えうる欠点は、<tt>'$*'</tt> を使っているため、
<tt/command/ 内部でシングルクォートを用いると
 <tt/su/ コマンドの引数 (<tt>'$*'</tt>) が壊れてしまうことです。
もし他にもなにか深刻な間違いがあったら、著者に email を書き送って
ください。

<p>
<!--
Call the script <tt>/usr/local/bin/xsu</tt>, and you can do:
-->
スクリプトを <tt>/usr/local/bin/xsu</tt> とすれば

<tscreen><verb>
xsu clientuser 'command &'
</verb></tscreen>

<!--
-->
とできます。

<p>
<!--
Can't be much easier, unless you get rid of the password.  Yes, there
are ways for that too (<tt/sudo/), but this is not the place for that.
-->
パスワードを使う限り、これ以上そう簡単にはできません。
ええ、(<tt/sudo/) を使う方法もありますね。でもここでは扱いません。

<!--
<sect1> Client User Is Root
-->
<sect1> クライアントユーザが root

<p>
<!--
Obviously, anything that works for non-root client users is going to
work for root as well.  However, with root you can make it even easier,
because root can read anyone's <tt>~/.Xauthority</tt> file.  There's no
need to transfer the cookie.  All you have to do is set <tt/DISPLAY/, and
point <tt/XAUTHORITY/ to <tt>~serveruser/.Xauthority</tt>.  So you can do:
-->
当然、root ではないクライアントユーザが root で動作することも同様にできます。
しかし、root はすべての人の <tt>&tilde;/.Xauthority</tt> ファイルを読むことが
できるので、root の場合はより簡単です。クッキーを送る必要がありません。
 <tt/DISPLAY/ 環境変数を設定し、<tt/XAUTHORITY/ が
 <tt>&tilde;serveruser/.Xauthority</tt> を見るように設定するだけです。つまり:


<tscreen><verb>
su - -c "exec env DISPLAY='$DISPLAY' \
                  XAUTHORITY='${XAUTHORITY-$HOME/.Xauthority}' \
                  command"
</verb></tscreen>

<p>
<!--
Putting it into a script would give something like:
-->
これをスクリプト中に書くと以下のようになるでしょう。

<tscreen><verb>
#!/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 '$*'"
</verb></tscreen>

<p>
<!--
Call the script <tt>/usr/local/bin/xroot</tt>, and you can do:
-->
スクリプトを <tt>/usr/local/bin/xroot</tt> とすれば

<tscreen><verb>
xroot 'control-panel &'
</verb></tscreen>

<!--
-->
とできます。

<p>
<!--
Although, if you've set up <tt/xsu/ already, there's no real reason to
do this.
-->
でも、もし <tt/xsu/ をすでに設定してあれば、
このようにしなければならない理由はありません。

<!--
<sect> Running a Remote Window Manager
-->
<sect> リモートウィンドウマネージャの実行

<p>
<!--
A window manager (like <tt/twm/, <tt/wmaker/, or <tt/fvwm95/) is an
application like any other.  The normal procedure should work.
-->
ウィンドウマネージャ (<tt/twm/、<tt/wmaker/ や <tt/fvwm95/ のような) は
他のアプリケーションと同様に扱えます。普通の手順で動かせます。

<p>
<!--
Well, almost.  At most one window manager can be running on a display at
any time.  If you are already running a local window manager, you cannot
start the remote one (it will complain and exit).  You have to kill
(or simply quit) the local one first.
-->
ほとんどの場合うまくいきます。最高で一つのウィンドウマネージャをいつでも
ディスプレイで実行できます。すでにローカルウィンドウマネージャが実行され
ているのなら、リモートウィンドウマネージャを起動することは
できません (それは不平を言い終了するでしょう)。最初に
ローカルウィンドウマネージャを kill(または単に quit) しなければなりません。

<p>
<!--
Unfortunately, many X session scripts end with an
-->
残念ながら、多くの X セッションスクリプトはこの１行で終わります。

<tscreen><verb>
exec window-manager-of-choice
</verb></tscreen>

<!--
and this means that when the (local) window manager exits, your session
exits, and the X system (xdm or xinit) considers your session over and
effectively logs you out.
-->
そして、これは (ローカルの)ウィンドウマネージャが終了した時に、
セッションが終了することを意味します。
X システム (xdm か xinit) にセッションが終了したとみなされると、
実際にはログアウトさせられてしまいます。

<p>
<!--
You have to jump through a few extra hoops, but it can be done and
it's not too difficult.  Just play with your session script (normally
<tt>~/.xsession</tt> or <tt>~/.xinitrc</tt>) to get it as you want it.
-->
いくつか特別なことを行わなければなりませんが、実行は可能でそんなに
難しくありません。あなたが欲するとおりに、セッションスクリプト (普通は
 <tt>&tilde;/.xsession</tt> か <tt>&tilde;/.xinitrc</tt>) をちょっと
いじるだけです。

<p>
<!--
Beware that a window manager often provides ways to run new programs,
and that these will run on the local machine.  That is, local to where
the window manager runs.  If you run a remote window manager, it will
spawn remote applications, and this may not be what you want.  Of course,
they still display on the display that is local to you.
-->
多くの場合、ウィンドウマネージャは新しいプログラムの実行方法を提供しますが、
それで実行したプログラムはローカルマシン上で実行されることに注意してください。
ここで言うローカルとはウィンドウマネージャが起動しているマシンを指します。
リモートでウィンドウマネージャを実行した場合は、リモートのアプリケーションが
起動されます。これはあなたの希望とは異なるかもしれません。もちろん、リモートで
起動したプログムは、依然として手元のディスプレイに表示を行います。

<!--
<sect> Troubleshooting
-->
<sect> トラブルシューティング

<p>
<!--
The first time you try to run a remote X application, it usually does
not work. Here are a few common error messages, their probable causes,
and solutions to help you on your way.
-->
初めてリモート X アプリケーションを実行しようとしても、
大抵はそのままでは動作しません。
以下２〜３のエラーメッセージ、原因、解決方法を挙げます。

<tscreen><verb>
xterm Xt error: Can't open display:
</verb></tscreen>

<!--
There is no <tt/DISPLAY/ variable in the environment, and you didn't
tell the application with the <tt/-display/ flag either. The application
assumes the empty string, but that is syntactically invalid. To solve
this, be sure that you set the <tt/DISPLAY/ variable correctly in the
environment (with <tt/setenv/ or <tt/export/ depending on your shell).
-->
<tt/DISPLAY/ 環境変数がなく、またアプリケーションに <tt/-display/ フラグも
指定していません。アプリケーションは空の文字列を想定しますが、構文上無効です。
この解決には、<tt/DISPLAY/ 環境変数を正しく設定しておきます (シェルによって
 <tt/setenv/ か <tt/export/ のどちちらかを使います)。

<tscreen><verb>
_X11TransSocketINETConnect: Can't connect: errno = 101
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
</verb></tscreen>

<!--
Errno 101 is ``Network is unreachable''.  The application could not make
a network connection to the server.  Check that you have the correct
<tt/DISPLAY/ set, and that the server machine is reachable from your
client (it should be, after all you're probably logged in to the server
and telnetting to the client).
-->
エラー 101 は &dquot;Network is unreachable&dquot; です。アプリケーションは
サーバにネットワーク接続できません。<tt/DISPLAY/ の設定が
正しいかどうかと、サーバマシンにクライアントから到達できるかどうか (サーバに
ログインした後、クライアントに telnet してみるなど) を確認してください。

<tscreen><verb>
_X11TransSocketINETConnect: Can't connect: errno = 111
xterm Xt error: Can't open display: love.dial.xs4all.nl:0
</verb></tscreen>

<!--
Errno 111 is ``Connection refused''.  The server machine you're trying
to connect to is reachable, but the indicated server does not exist
there. Check that you are using the right host name and the right
display number.
-->
エラー 111 は &dquot;Connection refused&dquot; です。接続しようと
しているサーバマシンには到達しますが、指定したサーバがありません。
ホスト名とディスプレイ番号を正しく使っているか確認してください。

<tscreen><verb>
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
</verb></tscreen>

<!--
The client could make a connection to the server, but the server does
not allow the client to use it (not authorized). Make sure that you have
transported the correct magic cookie to the client, and that it has not
expired (the server uses a new cookie when a new session starts).
-->
クライアントはサーバに接続を作れましたが、サーバは
 (認証されていない) クライアントがディスプレイを使うことを許しません。
正しいマジッククッキーをクライアントに転送し、その期限が切れていないか
 (新しいセッションを開始する時、サーバは新しいクッキーを使います)
 確認してください。

<sect>日本語訳について
<p>
日本語訳は Linux Japanese FAQ Project が行いました。
翻訳に関するご意見は JF プロジェクト
&lt;JF@linux.or.jp&gt;
宛に連絡してください。

改訂履歴を以下に示します。
<!--
お名前はメールのご署名より、転記させていただきました。
問題がございましたら、ご指摘ください。
 --> 

<descrip>
<tag>v0.3.1</tag>
翻訳:
Tetsu Isaji &lt;isaji@mxu.mesh.ne.jp&gt;

<verb>
Kerberosについて：
うえやま るいさん <rui@ic.netlaputa.ne.jp>、
岡本 一幸さん <kokamoto@ad.vc-net.ne.jp>、
Jun Kuwamuraさん <juk@rccm.co.jp>
</verb>

<tag>v0.6.3</tag>
翻訳:
野本浩一 &lt;hng@ps.ksky.ne.jp&gt;

<verb>
校正：
藤原 輝嘉さん <fujiwara@linux.or.jp>、
加藤 大典さん <daisuke@terra.dti.ne.jp>、
高城 正平さん <takavoid@palette.plala.or.jp>、
Toshimi Horie さん <je2uff@mxa.mesh.ne.jp>、
武井 伸光さん <takei@webmasters.gr.jp>、
中谷 千絵さん <jeanne@mbox.kyoto-inet.or.jp>、
中野 武雄さん <nakano@apm.seikei.ac.jp>、
森本 淳さん <morimoto@xantia.citroen.org>、
Hiro YAMAZAKI さん <hiro@linux.or.jp>、
Tsutomu Kawashima さん <kawawa@mail.interq.or.jp>、
後藤 雅晴さん <magotou@fubyshare.gr.jp>、
佐野 武俊さん <kgh12351@nifty.ne.jp>、
岡本 一幸さん <kokamoto@ad.vc-net.ne.jp>
</verb>
</descrip>

</article>
