Provided by: manpages-ja_0.5.0.0.20071115-1_all bug

RFC 931

       RFC    931    などに基づく問い合わせが邑な場合   (これはコンパイル時の
       オプション設定)、tcpd              はクライアントユーザの名前を検証しよ
       うと試みる。これは、クライアントホストが    RFC    931   互換のデーモン
       を動作させている場合にだけ成功する。このクライアントユーザ名の問
       い合わせは、データ指向の高いコネクションに対しては機能せず、また
       パーソナルシステム(PCs)        からの接続の場合は、著しく遅くなるかも知
       れない。

例
       tcpd     の利用法の詳細は、コンパイル時にプログラムの中に入れ    られた
       pathname に依存する。

 1
       この例では、tcpd               は、オリジナルのネットワークデーモンが別
       の場所に移動されることを期待している。

       finger   サービスへのアクセスを監視するためには、オリジナル  の  finger
       デーモンは別の場所へと移動し、元々 finger デーモンがい た場所には  tcpd
       をインストールする。設定ファイルへの変更は必要な い。

            # mkdir /other/place
            # mv /usr/etc/in.fingerd /other/place
            # cp tcpd /usr/etc/in.fingerd

       この例では、ネットワークデーモンは     /usr/etc    にあるものとする。シ
       ステムによっては、ネットワークデーモンは /usr/sbin または  /usr/libexec
       に置かれていたり、名前の頭に           `in.'           という文字を持っ
       ていなかったりする。

 2
       この例で       tcpd        は、ネットワークデーモンは、そのオリジナルの
       場所に置かれている事を想定している。

       finger   サービスへのアクセスを監視するためには、次に示すよ  うな変更を
       inetd    の設定ファイル    (大抵の場合、     /etc/inetd.conf     または
       /etc/inet/inetd.conf) に対し て行なう:

            finger  stream  tcp  nowait  nobody  /usr/etc/in.fingerd  in.fingerd

       これを次のように:

            finger  stream  tcp  nowait  nobody  /some/where/tcpd     in.fingerd

       この例では、ネットワークデーモンは     /usr/etc    にあるものとする。シ
       ステムによっては、ネットワークデーモンは /usr/sbin または  /usr/libexec
       に置かれていたり、名前の頭に           `in.'           という文字を持っ
       ていなかったり、あるいは   inetd   の設定ファイルには   userid   の項目
       が存在しないこともある。

       似たような変更が、tcpd               でカバーされるその他のサービスに対
       しても必要になるだろう。変更を邑なものとするため、            inetd(8)
       のプロセスに対して  `kill  -HUP'  を送出する。AIX  のユーザは `inetimp'
       コマンドも実行する必要があるかもしれない。

 3
       デーモンが普通でないディレクトリ("secret"         やその他)に置かれてい
       る場合、inetd              の設定ファイルを編集して、プロセス名の項には
       絶対パス名で明示するように。例:

           ntalk  dgram  udp  wait  root  /some/where/tcpd  /usr/local/lib/ntalkd

       パス名の一番最後の要素 (ntalkd) だけがアクセスコントロールと、ロ グの-
       録に使われる。

グ
       いくつかの   UDP   (そして   RPC)  デーモンは、その仕事が終わって、別の
       リクエストがやって来ても、しばらくの間、名残惜しそうにプロセス空
       間をうろついている。これらのサービスは、inetd        の設定ファイルの中
       で、wait               オプションとともに登録されている。このようなデー
       モンは、それを起動したリクエストだけがログに杵燭気譴襪海箸砲覆襦

       プログラムは、TCP    経由の    RPC   サービスにおいては動作しない。これ
       らのサービスは、inetd       の設定ファイルの中で、rpc/tcp        として
       登録されている。この制限によって影響される唯一特別なサービスは、  on(1)
       コマンドによって利用されるrexd                         である。しかし、
       これは大したロスではない。大抵のシステムにおいて、rexd               は
       /etc/hosts.equiv の中のワイルドカードよりも安全度が低いのだ。

       RPC  broadcast   リクエスト   (例:   rwall,   rup,   rusers)   が、応答
       のあるホストから常にやってくることがある。クライアントが、そのネッ
       トワーク上の全ての        portmap         デーモンに対してブロードゥ礇
       トしている、というのがその実態である;      どの      portmap     デーモ
       ンも、リクエストはローカルのデーモンへと転送する。rwall              な
       どのデーモンが知る限り、リクエストはローカルホストから送られてく
       るのである。

ル
       ホストアクセスコントロールテーブル:

       /etc/hosts.allow
       /etc/hosts.deny

目
       hosts_access(5), ホストアクセスコントロールファイルの書式
       syslog.conf(5), syslogd コントロールファイルの書式
       inetd.conf(5), the inetd コントロールファイルの書式

者
       Wietse Venema (wietse@wzv.win.tue.nl),
       Department of Mathematics and Computing Science,
       Eindhoven University of Technology
       Den Dolech 2, P.O. Box 513,
       5600 MB Eindhoven, The Netherlands

訳
       FUKUSHIMA Osamu <fuku@amorph.rim.or.jp>

                                                                       TCPD(8)