RFC1196 日本語訳

Network Working Group                                       D. Zimmerman
Request for Comments: 1196           Center for Discrete Mathematics and
Obsoletes: RFCs 1194, 742                   Theoretical Computer Science
                                                           December 1990

コメントを求めるワーキンググループD.ジンマーマン要求をネットワークでつないでください: 1196は、以下を離散的な数学のために中心に置いて、時代遅れにします。 コンピュータサイエンス1990年12月の理論上のRFCs1194、742

                  The Finger User Information Protocol

指のユーザー情報プロトコル

Status of this Memo

このMemoの状態

   This memo defines a protocol for the exchange of user information.
   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

このメモはユーザー情報の交換のためにプロトコルを定義します。 このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This memo describes the Finger User Information Protocol.  This is a
   simple protocol which provides an interface to a remote user
   information program.

このメモはFinger User情報プロトコルについて説明します。 これはリモート・ユーザー情報プログラムにインタフェースを供給する簡単なプロトコルです。

   Based on RFC 742, a description of the original Finger protocol, this
   memo attempts to clarify the expected communication between the two
   ends of a Finger connection.  It also tries not to invalidate the
   many existing implementations or add unnecessary restrictions to the
   original protocol definition.  This edition corrects and clarifies in
   a minor way, RFC 1194.

RFC742、オリジナルのFingerプロトコルの記述に基づいて、このメモは、Finger接続の2つの終わりの予想されたコミュニケーションをはっきりさせるのを試みます。 それは、多くの既存の実装を無効にしないようにするか、またはまた、オリジナルのプロトコル定義に不要な制限を加えないようにします。 RFC1194、この版は、小さい方の方法で修正して、はっきりさせられます。

Table of Contents

目次

1.      Introduction  ...........................................   2
  1.1.    Intent  ...............................................   2
  1.2.    History  ..............................................   3
  1.3.    Requirements  .........................................   3
2.      Use of the protocol  ....................................   3
  2.1.    Flow of events  .......................................   3
  2.2.    Data format  ..........................................   4
  2.3.    Query specifications  .................................   4
  2.4.    RUIP {Q2} behavior  ...................................   4
  2.5.    Expected RUIP response  ...............................   5
    2.5.1.  {C} query  ..........................................   5
    2.5.2.  {U}{C} query  .......................................   6
    2.5.3.  {U} ambiguity  ......................................   6
    2.5.4.  /W query token  .....................................   6
    2.5.5.  Vending machines  ...................................   7
3.      Security  ...............................................   7

1. 序論… 2 1.1. 意図… 2 1.2. 歴史… 3 1.3. 要件… 3 2. プロトコルの使用… 3 2.1. イベントの流れ… 3 2.2. データの形式… 4 2.3. 仕様を質問してください… 4 2.4. RUIP Q2、振舞い… 4 2.5. RUIP応答を予想します… 5 2.5.1. C、質問… 5 2.5.2. Cが質問するu… 6 2.5.3. uあいまいさ… 6 2.5.4. /W質問トークン… 6 2.5.5. 自動販売機… 7 3. セキュリティ… 7

Zimmerman                                                       [Page 1]

RFC 1196                         Finger                    December 1990

ジンマーマン[1ページ]のRFCの1196年の指の1990年12月

  3.1.    Implementation security  ..............................   7
  3.2.    RUIP security  ........................................   7
    3.2.1.  {Q2} refusal  .......................................   7
    3.2.2.  {C} refusal  ........................................   8
    3.2.3.  Atomic discharge  ...................................   8
    3.2.4.  User information files  .............................   8
    3.2.5.  Execution of user programs  .........................   9
    3.2.6.  {U} ambiguity  ......................................   9
    3.2.7.  Audit trails  .......................................   9
  3.3.    Client security  ......................................   9
4.      Examples  ...............................................  10
  4.1.    Example with a null command line ({C})  ...............  10
  4.2.    Example with name specified ({U}{C})  .................  10
  4.3.    Example with ambiguous name specified ({U}{C})  .......  11
  4.4.    Example of query type {Q2} ({U}{H}{H}{C})  ............  11
5.      Acknowledgments  ........................................  12
6.      Security Considerations  ................................  12
7.      Author's Address  .......................................  12

3.1. 実装セキュリティ… 7 3.2. RUIPセキュリティ… 7 3.2.1. Q2、拒否… 7 3.2.2. C、拒否… 8 3.2.3. 原子放出… 8 3.2.4. ユーザー情報はファイルされます… 8 3.2.5. ユーザ・プログラムの実行… 9 3.2.6. uあいまいさ… 9 3.2.7. 道を監査してください… 9 3.3. クライアントセキュリティ… 9 4. 例… 10 4.1. ヌルコマンドライン(C)がある例… 10 4.2. 名前がある例は(u C)を指定しました… 10 4.3. あいまいな名前がある例は(u C)を指定しました… 11 4.4. 質問タイプQ2に関する例、(u H、H、C)、… 11 5. 承認… 12 6. セキュリティ問題… 12 7. 作者のアドレス… 12

1.  Introduction

1. 序論

1.1.  Intent

1.1. 意図

   This memo describes the Finger User Information Protocol.  This is a
   simple protocol which provides an interface to a remote user
   information program (RUIP).

このメモはFinger User情報プロトコルについて説明します。 これはリモート・ユーザー情報プログラム(RUIP)にインタフェースを提供する簡単なプロトコルです。

   Based on RFC 742, a description of the original Finger protocol, this
   memo attempts to clarify the expected communication between the two
   ends of a Finger connection.  It also tries not to invalidate the
   many current implementations or add unnecessary restrictions to the
   original protocol definition.

RFC742、オリジナルのFingerプロトコルの記述に基づいて、このメモは、Finger接続の2つの終わりの予想されたコミュニケーションをはっきりさせるのを試みます。 それは、多くの現在の実装を無効にしないようにするか、またはまた、オリジナルのプロトコル定義に不要な制限を加えないようにします。

   The most prevalent implementations of Finger today seem to be
   primarily derived from the BSD UNIX work at the University of
   California, Berkeley.  Thus, this memo is based around the BSD
   version's behavior.

Fingerの最も一般的な実装は今日、カリフォルニア大学バークレイ校でBSD UNIX仕事から主として得られるように思えます。 したがって、このメモはBSDバージョンの振舞いの周りに基づいています。

   However, the BSD version provides few options to tailor the Finger
   RUIP for a particular site's security policy, or to protect the user
   from dangerous data.  Furthermore, there are MANY potential security
   holes that implementors and administrators need to be aware of,
   particularly since the purpose of this protocol is to return
   information about a system's users, a sensitive issue at best.
   Therefore, this memo makes a number of important security comments
   and recommendations.

しかしながら、BSDバージョンは、特定のサイトの安全保障政策のためにFinger RUIPを仕立てるか、または危険なデータからユーザを保護するためにわずかなオプションしか提供しません。 その上、作成者と管理者が意識しているために必要とするせいぜい特にシステムのユーザの情報を返して以来のこのプロトコルの目的がことであるデリケートな問題のMANYの潜在的セキュリティーホールがあります。 したがって、このメモは多くの重要なセキュリティをコメントと推薦にします。

Zimmerman                                                       [Page 2]

RFC 1196                         Finger                    December 1990

ジンマーマン[2ページ]のRFCの1196年の指の1990年12月

1.2.  History

1.2. 歴史

   The FINGER program at SAIL, written by Les Earnest, was the
   inspiration for the NAME program on ITS.  Earl Killian at MIT and
   Brian Harvey at SAIL were jointly responsible for implementing the
   original protocol.

レスEarnestによって書かれたSAILのFINGERプログラムはITSのNAMEプログラムのためのインスピレーションでした。 MITの伯爵キリアーンとSAILのブライアン・ハーヴェイは共同でオリジナルのプロトコルを実装するのに責任がありました。

   Ken Harrenstien is the author of RFC 742, "Name/Finger", which this
   memo began life as.

ケンHarrenstienはRFC742の作者、このメモが寿命を始めた「名前/指」です。

1.3.  Requirements

1.3. 要件

   In this document, the words that are used to define the significance
   of each particular requirement are capitalized.  These words are:

本書では、それぞれの特定の要件の意味を定義するのに使用される単語は大文字で書かれます。 これらの単語は以下の通りです。

   * "MUST"

* "MUST"

      This word or the adjective "REQUIRED" means that the item is an
      absolute requirement of the specification.

「必要である」というこの単語か形容詞が、項目が仕様に関する絶対条件であることを意味します。

   * "SHOULD"

* "SHOULD"

      This word or the adjective "RECOMMENDED" means that there may
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and the case
      carefully weighed before choosing a different course.

この単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを選ぶ前に慎重に熟慮されたケースであるべきです。

   * "MAY"

* 「5月」

      This word or the adjective "OPTIONAL" means that this item is
      truly optional.  One vendor may choose to include the item because
      a particular marketplace requires it or because it enhances the
      product, for example; another vendor may omit the same item.

「任意である」というこの単語か形容詞が、本当に、この項目が任意であることを意味します。 特定の市場がそれを必要とするか、または例えば製品を高めるので、1つのベンダーが、項目を含んでいるのを選ぶかもしれません。 別のベンダーは同じ項目を省略するかもしれません。

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST requirements.  An implementation that satisfies all the
   MUST and all the SHOULD requirements is said to be "unconditionally
   compliant"; one that satisfies all the MUST requirements but not all
   the SHOULD requirements is said to be "conditionally compliant".

1つか以上を満たさないなら実装が対応でない、要件はそうしなければなりません。 そして、すべてを満たす実装、すべてのSHOULD要件が「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、すべてのSHOULD要件だけが「条件付きに言いなりになる」と言われているというわけではないという要件はそうしなければなりません。

2.  Use of the protocol

2. プロトコルの使用

2.1.  Flow of events

2.1. イベントの流れ

   Finger is based on the Transmission Control Protocol, using TCP port
   79 decimal (117 octal).  A TCP connection is opened to a remote host
   on the Finger port.  An RUIP becomes available on the remote end of
   the connection to process the request.  The RUIP is sent a one line

TCPポート79小数(117 8進)を使用して、指は通信制御プロトコルに基づいています。 TCP接続はFingerポートの上でリモートホストに公開されます。 RUIPは、要求を処理するために接続のリモートエンドで利用可能になります。 1つの系列をRUIPに送ります。

Zimmerman                                                       [Page 3]

RFC 1196                         Finger                    December 1990

ジンマーマン[3ページ]のRFCの1196年の指の1990年12月

   query based upon the Finger query specification.  The RUIP processes
   the query, returns an answer, then closes the connection normally.

Finger質問仕様に基づく質問。 RUIPは質問を処理して、返答して、次に、通常、接続を終えます。

2.2.  Data format

2.2. データの形式

   Any data transferred MUST be in ASCII format, with no parity, and
   with lines ending in CRLF (ASCII 13 followed by ASCII 10).  This
   excludes other character formats such as EBCDIC, etc.  This also
   means that any characters between ASCII 128 and ASCII 255 should
   truly be international data, not 7-bit ASCII with the parity bit set.

同等なしでASCII書式、および系列がCRLFに終わっていて、移されたどんなデータもあるに違いありません(ASCII13はASCII10で続きました)。 これはEBCDICなどの他のキャラクタ形式を遮断します。 また、これは、本当に、ASCII128とASCII255の間のどんなキャラクタもパリティビットセットがある7ビットのASCIIではなく、国際的なデータであることを意味します。

2.3.  Query specifications

2.3. 質問仕様

   An RUIP MUST accept the entire Finger query specification.

RUIP MUSTは全体のFinger質問仕様を受け入れます。

   The Finger query specification is defined:

Finger質問仕様は定義されます:

        {Q1}    ::= [{U}] [/W] {C}

Q1:、:= [U] [/W]C

        {Q2}    ::= [{U}]{H} [/W] {C}

Q2:、:= [U] H[/W]C

        {U}     ::= username

U:、:= ユーザ名

        {H}     ::= @hostname | @hostname{H}

H:、:= @hostname| @hostnameH

        {C}     ::= <CRLF>

C:、:= <CRLF>。

   {H}, being recursive, means that there is no arbitrary limit on the
   number of @hostname tokens in the query.  In examples of the {Q2}
   request specification, the number of @hostname tokens is limited to
   two, simply for brevity.

再帰的であることで、Hは、どんな任意の限界も質問における、@hostnameトークンの数にないことを意味します。 Q2に関する例では、仕様を要求してください、そして、@hostnameトークンの数は単に簡潔さのために2に制限されます。

   Be aware that {Q1} and {Q2} do not refer to a user typing "finger
   user@host" from an operating system prompt.  It refers to the line
   that an RUIP actually receives.  So, if a user types "finger
   user@host<CRLF>", the RUIP on the remote host receives "user<CRLF>",
   which corresponds to {Q1}.

Q1とQ2がオペレーティングシステムプロンプトから「指の user@host 」をタイプしているユーザについて言及しないのを意識してください。 それはRUIPが実際に受ける台詞について言及します。 そのように、ユーザがタイプするなら「 user@host を弄ってください、lt;、CRLF>、」、リモートホストの上のRUIPは「ユーザ<CRLF>」を受けます。(それは、Q1に対応します)。

   As with anything in the IP protocol suite, "be liberal in what you
   accept".

IPプロトコル群の何のように「あなたが受け入れるものでは、寛容であってください。」でも

2.4.  RUIP {Q2} behavior

2.4. RUIP Q2、振舞い

   A query of {Q2} is a request to forward a query to another RUIP.  An
   RUIP MUST either provide or actively refuse this forwarding service
   (see section 3.2.1).  If an RUIP provides this service, it MUST
   conform to the following behavior:

Q2の質問は別のRUIPに質問を送るという要求です。 RUIP MUSTは提供するか、または活発にこの推進サービスを拒否します(セクション3.2.1を見てください)。 RUIPがこのサービスを提供するなら、以下の振舞いに従わなければなりません:

Zimmerman                                                       [Page 4]

RFC 1196                         Finger                    December 1990

ジンマーマン[4ページ]のRFCの1196年の指の1990年12月

   Given that:

それを与えます:

         Host <H1> opens a Finger connection <F1-2> to an RUIP on host
         <H2>.

ホスト<H1>はFinger接続<F1-2>をホスト<H2>の上のRUIPに開きます。

         <H1> gives the <H2> RUIP a query <Q1-2> of type {Q2}
         (e.g., FOO@HOST1@HOST2).

<H1>はタイプQ2(例えば、FOO@HOST1@HOST2)の質問<Q1-2>を<H2>RUIPに与えます。

   It should be derived that:

以下のことは引き出しているべきです。

         Host <H3> is the right-most host in <Q1-2> (i.e., HOST2)

ホスト<H3>は<Q1-2>の最も権利ホストです。(すなわち、HOST2)

         Query <Q2-3> is the remainder of <Q1-2> after removing the
         right-most "@hostname" token in the query (i.e., FOO@HOST1)

質問<Q2-3>は質問における最も権利"@hostname"トークンを取り除いた後の<Q1-2>の残りです。(すなわち、 FOO@HOST1 )

   And so:

そう:

         The <H2> RUIP then must itself open a Finger connection <F2-3>
         to <H3>, using <Q2-3>.

そして、<H2>RUIPは<Q2-3>を使用する<H3>へのそれ自体でオープンなa Finger接続<F2-3>がそうしなければなりません。

         The <H2> RUIP must return any information received from <F2-3>
         to <H1> via <F1-2>.

<H2>RUIPは<F1-2>を通して<F2-3>から<H1>まで受け取られたどんな情報も返さなければなりません。

         The <H2> RUIP must close <F1-2> in normal circumstances only
         when the <H3> RUIP closes <F2-3>.

<H3>RUIPが<F2-3>を閉じる場合にだけ、<H2>RUIPは平常な時に<F1-2>を閉じなければなりません。

2.5.  Expected RUIP response

2.5. 予想されたRUIP応答

   For the most part, the output of an RUIP doesn't follow a strict
   specification, since it is designed to be read by people instead of
   programs.  It should mainly strive to be informative.

だいたい、RUIPの出力は厳しい仕様に従いません、プログラムの代わりに人々によって読まれるようにそれが設計されているので。それは、有益であるように主に努力するべきです。

   Output of ANY query is subject to the discussion in the security
   section.

どんな質問の出力もセキュリティ部での議論を受けることがあります。

2.5.1.  {C} query

2.5.1. Cは質問します。

   A query of {C} is a request for a list of all online users.  An RUIP
   MUST either answer or actively refuse (see section 3.2.2).  If it
   answers, then it MUST provide at least the user's full name.  The
   system administrator SHOULD be allowed to include other useful
   information (per section 3.2.3), such as:

Cの質問はすべてのオンラインユーザのリストに関する要求です。 RUIP MUSTは答えるか、または活発に拒否します(セクション3.2.2を見てください)。 答えるなら、それは少なくともユーザのフルネームを提供しなければなりません。 システム管理者SHOULD、以下などの他の役に立つ情報(セクション3.2.3あたりの)は含まされてください。

      -    terminal location
      -    office location
      -    office phone number
      -    job name
      -    idle time (number of minutes since last typed input, or

- 端末の位置--店舗立地--オフィスは数--ジョブ名--遊休時間に電話をします。または(数分の数が最後に以来入力をタイプした。

Zimmerman                                                       [Page 5]

RFC 1196                         Finger                    December 1990

ジンマーマン[5ページ]のRFCの1196年の指の1990年12月

           since last job activity).

以来、最後の仕事の活動)

2.5.2.  {U}{C} query

2.5.2. Cが質問するu

   A query of {U}{C} is a request for in-depth status of a specified
   user {U}.  If you really want to refuse this service, you probably
   don't want to be running Finger in the first place.

u Cの質問は指定されたユーザuの徹底的な状態を求めて要求です。 本当にこのサービスを拒否したいなら、あなたは第一に、たぶん実行しているFingerになりたがっていません。

   An answer MUST include at least the full name of the user.  If the
   user is logged in, at least the same amount of information returned
   by {C} for that user MUST also be returned by {U}{C}.

答えは少なくともユーザのフルネームを含まなければなりません。 ユーザがログインされるなら、少なくとも返して、また、そのユーザのためのCをu Cで返さなければならないという情報の同じ量です。

   Since this is a query for information on a specific user, the system
   administrator SHOULD be allowed to choose to return additional useful
   information (per section 3.2.3), such as:

以来これが特定のユーザ、システム管理者SHOULDの情報のための質問である、以下などの追加役に立つ情報(セクション3.2.3あたりの)を返すのを選ぶのが許容されてください。

      -    office location
      -    office phone number
      -    home phone number
      -    status of login (not logged in, logout time, etc)
      -    user information file

- 電話が付番する店舗立地--オフィス--自宅電話番号--ログインの状態、(ログインされていません、ログアウトしてください、時間など)、--ユーザー情報がファイルされる

   A user information file is a feature wherein a user may leave a short
   message that will be included in the response to Finger requests.
   (This is sometimes called a "plan" file.)  This is easily implemented
   by (for example) having the program look for a specially named text
   file in the user's home directory or some common area; the exact
   method is left to the implementor.  The system administrator SHOULD
   be allowed to specifically turn this feature on and off.  See section
   3.2.4 for caveats.

ユーザ調査資料ファイルはユーザがFinger要求への応答に含まれている短いメッセージを残すかもしれない特徴です。 (これは時々「プラン」ファイルと呼ばれます。) (例えば) プログラムにユーザのホームディレクトリか何らかの一般的な領域で特に、命名されたテキストファイルを探させることによって、これは容易に実装されます。 正確なメソッドは作成者に任せます。 システム管理者SHOULD、この特徴は断続的に明確に変えさせられてください。 警告に関してセクション3.2.4を見てください。

   There MAY be a way for the user to run a program in response to a
   Finger query.  If this feature exists, the system administrator
   SHOULD be allowed to specifically turn it on and off.  See section
   3.2.5 for caveats.

ユーザがFinger質問に対応してプログラムを動かす方法があるかもしれません。 特徴はこれであるなら存在していて、システム管理者はSHOULDです。それは断続的に明確にターンさせられてください。 警告に関してセクション3.2.5を見てください。

2.5.3.  {U} ambiguity

2.5.3. uあいまいさ

   Allowable "names" in the command line MUST include "user names" or
   "login names" as defined by the system.  If a name is ambiguous, the
   system administrator SHOULD be allowed to choose whether or not all
   possible derivations should be returned in some fashion (per section
   3.2.6).

コマンドラインの許容できる「名前」はシステムによって定義されるように「ユーザ名」か「ログイン名」を含まなければなりません。 名前はaであるならあいまいです、システム管理者SHOULD。何らかのファッション(セクション3.2.6あたりの)ですべての可能な派生が返されるべきであるかどうかを選ぶのが許容されてください。

2.5.4.  /W query token

2.5.4. /W質問トークン

   The token /W in the {Q1} or {Q2} query types SHOULD at best be
   interpreted at the last RUIP to signify a higher level of verbosity

中のQ1かQ2が質問するトークン/WがせいぜいSHOULDをタイプする、 より高いレベルのくどさを意味する最後のRUIPで解釈されてください。

Zimmerman                                                       [Page 6]

RFC 1196                         Finger                    December 1990

ジンマーマン[6ページ]のRFCの1196年の指の1990年12月

   in the user information output, or at worst be ignored.

ユーザ情報生産量、または最悪の場合は無視されてください。

2.5.5.  Vending machines

2.5.5. 自動販売機

   Vending machines SHOULD respond to a {C} request with a list of all
   items currently available for purchase and possible consumption.
   Vending machines SHOULD respond to a {U}{C} request with a detailed
   count or list of the particular product or product slot.  Vending
   machines should NEVER NEVER EVER eat requests.  Or money.

SHOULDがa Cに反応させる自動販売機は現在、購買に利用可能で可能なすべての項目のリストで消費を要求します。 自動販売機SHOULDはCが特定の製品か製品スロットの詳細なカウントかリストで要求するuに応じます。 自動販売機は食べるべきです。NEVER NEVER EVERは要求を食べます。 お金。

3.  Security

3. セキュリティ

3.1.  Implementation security

3.1. 実装セキュリティ

   Sound implementation of Finger is of the utmost importance.
   Implementations should be tested against various forms of attack.  In
   particular, an RUIP SHOULD protect itself against malformed inputs.
   Vendors providing Finger with the operating system or network
   software should subject their implementations to penetration testing.

Fingerの音の実装は最重要性のものです。 実装は様々な形式の攻撃に対してテストされるべきです。 特に、RUIP SHOULDは奇形の入力に対して我が身をかばいます。 オペレーティングシステムかネットワークソフトウェアをFingerに提供するベンダーはかけられるべきです。侵入テストへのそれらの実装。

   Finger is one of the avenues for direct penetration, as the Morris
   worm pointed out quite vividly.  Like Telnet, FTP and SMTP, Finger is
   one of the protocols at the security perimeter of a host.
   Accordingly, the soundness of the implementation is paramount.  The
   implementation should receive just as much security scrutiny during
   design, implementation, and testing as Telnet, FTP, or SMTP.

モリスワームが全く生き生きと指摘したように指はダイレクト侵入のための大通りの1つです。 Telnet、FTP、およびSMTPのように、Fingerはホストのセキュリティ周辺のプロトコルの1つです。 それに従って、実装の健全さは最高のです。 実装はデザインと、実装と、Telnet、FTP、またはSMTPとしてテストしている間、まさしく多くのセキュリティ精査を受け取るべきです。

3.2.  RUIP security

3.2. RUIPセキュリティ

   Warning!!  Finger discloses information about users; moreover, such
   information may be considered sensitive.  Security administrators
   should make explicit decisions about whether to run Finger and what
   information should be provided in responses.  One existing
   implementation provides the time the user last logged in, the time he
   last read mail, whether unread mail was waiting for him, and who the
   most recent unread mail was from!  This makes it possible to track
   conversations in progress and see where someone's attention was
   focused.  Sites that are information-security conscious should not
   run Finger without an explicit understanding of how much information
   it is giving away.

警告! 指はユーザに関して情報を開示します。 そのうえ、そのような情報は敏感であると考えられるかもしれません。 セキュリティ管理者はFingerを実行するかどうかと、どんな情報を応答に提供するべきであるかに関する明白な決定をするべきです。 1つの既存の実装が読まれていないメールが彼を待っていたか否かに関係なく、彼が最後にメールを読んだとき最終がログインして、最新の読まれていないメールが来ていたユーザを時間に提供します! これで、進行中の会話を追跡して、だれかの注意がどこで焦点を合わせられたかわかるのが可能になります。 情報セキュリティ意識しているサイトはそれがどのくらいの情報を漏らすかに関する明白な理解なしでFingerを実行するべきではありません。

3.2.1.  {Q2} refusal

3.2.1. Q2、拒否

   For individual site security concerns, the system administrator
   SHOULD be given an option to individually turn on or off RUIP
   processing of {Q2}.  If RUIP processing of {Q2} is turned off, the
   RUIP MUST return a service refusal message of some sort.  "Finger
   forwarding service denied" is adequate.  The purpose of this is to

個人は安全上の配慮を位置させます、システム管理者SHOULD。個別にターンするためにはQ2のRUIP処理のオプションをお願いします。 Q2のRUIP処理がオフにされるなら、RUIP MUSTはある種のサービス拒否メッセージを返します。 「サービスが否定した指の推進」は適切です。 この目的はあります。

Zimmerman                                                       [Page 7]

RFC 1196                         Finger                    December 1990

ジンマーマン[7ページ]のRFCの1196年の指の1990年12月

   allow individual hosts to choose to not forward Finger requests, but
   if they do choose to, to do so consistently.

個々のホストを何か前進のFinger要求にもかかわらず、それらが、選ばないかどうかに選んで、それほど一貫してさせてください。

   Overall, there are few cases which would warrant processing of {Q2}
   at all, and they are far outweighed by the number of cases for
   refusing to process {Q2}.  In particular, be aware that if a machine
   is part of security perimeter (that is, it is a gateway from the
   outside world to some set of interior machines), then turning {Q2} on
   provides a path through that security perimeter.  Therefore, it is
   RECOMMENDED that the default of the {Q2} processing option be to
   refuse processing.  It certainly should not be enabled in gateway
   machines without careful consideration of the security implications.

全体的に見て、処理するのを保証する全くQ2に関するケースがわずかしかありません、そして、それらは遠くにQ2を処理するのを拒否する件数より軽いです。 経路がマシンがセキュリティ周辺の一部(すなわち、それは外の世界から内部の何らかのセットのマシンへのゲートウェイである)であるならQ2をつけるとそのセキュリティ周辺を通して提供されるのを特に、意識してください。 したがって、それはQ2のデフォルトがオプションを処理して、処理を拒否することになっているRECOMMENDEDです。 確かに、ゲートウェイマシンでセキュリティ含意の熟慮なしでそれを可能にするべきではありません。

3.2.2.  {C} refusal

3.2.2. C、拒否

   For individual site security concerns, the system administrator
   SHOULD be given an option to individually turn on or off RUIP
   acceptance of {C}.  If RUIP processing of {C} is turned off, the RUIP
   MUST return a service refusal message of some sort.  "Finger online
   user list denied" is adequate.  The purpose of this is to allow
   individual hosts to choose to not list the users currently online.

個人は安全上の配慮を位置させます、システム管理者SHOULD。個別にターンするためにはCのRUIP承認のオプションをお願いします。 CのRUIP処理がオフにされるなら、RUIP MUSTはある種のサービス拒否メッセージを返します。 「オンラインユーザリストが否定した指」は適切です。 この目的は個々のホストが、現在オンラインでユーザを記載しないのを選ぶのを許容することです。

3.2.3.  Atomic discharge

3.2.3. 原子放出

   All implementations of Finger SHOULD allow individual system
   administrators to tailor what atoms of information are returned to a
   query.  For example:

質問に返して、Finger SHOULDの実装が情報の原子がものであることを仕立てるのを個人能率給制管理者を許容するすべて。 例えば:

      -    Administrator A should be allowed to specifically choose to
           return office location, office phone number, home phone
           number, and logged in/logout time.

- 管理者Aは、店舗立地を返すのを明確に選ぶことができるべきです、会社の電話番号、自宅電話番号、登録されて、/では、時間はログアウトしています。

      -    Administrator B should be allowed to specifically choose to
           return only office location, and office phone number.

- 管理者Bは、店舗立地、および会社の電話番号だけを返すのを明確に選ぶことができるべきです。

      -    Administrator C should be allowed to specifically choose to
           return the minimum amount of required information, which is
           the person's full name.

- 管理者Cは、最小の量の必須情報を返すのを明確に選ぶことができるべきです。(必須情報は人のフルネームです)。

3.2.4.  User information files

3.2.4. ユーザ調査資料ファイル

   Allowing an RUIP to return information out of a user-modifiable file
   should be seen as equivalent to allowing any information about your
   system to be freely distributed.  That is, it is potentially the same
   as turning on all specifiable options.  This information security
   breach can be done in a number of ways, some cleverly, others
   straightforwardly.  This should disturb the sleep of system
   administrators who wish to control the returned information.

RUIPがユーザ修正できるファイルから情報を返すのを許容するのがあなたのシステムのどんな情報も自由に分配されるのを許容するのに同等であるとみなされるべきです。 すなわち、それはすべての明記できるオプションをつけるのと潜在的に同じです。 他のもの、多くの方法で賢くこの情報機密保護違反がいくつかできます。まっすぐ。 これは返された情報を制御したがっているシステム管理者の睡眠を擾乱するべきです。

Zimmerman                                                       [Page 8]

RFC 1196                         Finger                    December 1990

ジンマーマン[8ページ]のRFCの1196年の指の1990年12月

3.2.5.  Execution of user programs

3.2.5. ユーザ・プログラムの実行

   Allowing an RUIP to run a user program in response to a Finger query
   is potentially dangerous.  BE CAREFUL!! -- the RUIP MUST NOT allow
   system security to be compromised by that program.  Implementing this
   feature may be more trouble than it is worth, since there are always
   bugs in operating systems, which could be exploited via this type of
   mechanism.

RUIPがFinger質問に対応してユーザ・プログラムを動かすのを許容するのは潜在的に危険です。 注意してください! -- そのプログラムでRUIP MUST NOTはシステムセキュリティを感染させます。 この特徴を実装するのは、それが価値があるより多くの問題であるかもしれません、オペレーティングシステム(このタイプのメカニズムで利用できる)にはバグがいつもあるので。

3.2.6.  {U} ambiguity

3.2.6. uあいまいさ

   Be aware that a malicious user's clever and/or persistent use of this
   feature can result in a list of most of the usernames on a system.
   Refusal of {U} ambiguity should be considered in the same vein as
   refusal of {C} requests (see section 3.2.2).

悪意あるユーザーのこの特徴の賢明な、そして/または、永続的な使用がシステムの上でユーザ名の大部分のリストをもたらすことができるのを意識してください。 uあいまいさの拒否はCの拒否と同じ静脈が要求するコネであると考えられるべきです(セクション3.2.2を見てください)。

3.2.7.  Audit trails

3.2.7. 監査証跡

   Implementations SHOULD allow system administrators to log Finger
   queries.

実装SHOULDはシステム管理者にFinger質問を登録させます。

3.3.  Client security

3.3. クライアントセキュリティ

   It is expected that there will normally be some client program that
   the user runs to query the initial RUIP.  By default, this program
   SHOULD filter any unprintable data, leaving only printable 7-bit
   characters (ASCII 32 through ASCII 126), tabs (ASCII 9), and CRLFs.
   This is to protect against people playing with terminal escape codes,
   changing other peoples' X window names, or committing other dastardly
   or confusing deeds.  Two separate user options SHOULD be considered
   to modify this behavior, so that users may choose to view
   international or control characters:

通常、ユーザが初期のRUIPについて質問するために動かすいくつかのクライアントプログラムがあると予想されます。 デフォルトで、このプログラムSHOULDはどんな印刷に適さないデータもフィルターにかけます、(ASCII126を通したASCII32)、タブ(ASCII9)、およびCRLFsに印刷可能な7ビットのキャラクタだけを発って。 これは端末のエスケープコードでプレーしている人々から守るためのものです、他の民族のX window名を変えるか、または他の卑劣であるか紛らわしい行為を遂行して。 この振舞い、ユーザが視点国際的に選ぶかもしれないそうまたは制御文字を変更するために考えられて、2はユーザ・オプションSHOULDを切り離します:

      -    one to allow all characters less than ASCII 32

- ASCII32より少ないすべてのキャラクタを許容する1

      -    another to allow all characters greater than ASCII 126

- ASCII126より偉大なすべてのキャラクタを許容する別

   For environments that live and breathe international data, the system
   administrator SHOULD be given a mechanism to enable the latter option
   by default for all users on a particular system.  This can be done
   via a global environment variable or similar mechanism.

環境には、それを生きています、そして、当然のことが特定のシステムの上のすべてのユーザのためにデフォルトで後者のオプションを可能にするメカニズムであったなら国際的なデータ、システム管理者SHOULDを吸い込んでください。 地球環境の可変であるか同様のメカニズムでこれができます。

Zimmerman                                                       [Page 9]

RFC 1196                         Finger                    December 1990

ジンマーマン[9ページ]のRFCの1196年の指の1990年12月

4.  Examples

4. 例

4.1.  Example with a null command line ({C})

4.1. ヌルコマンドラインがある例(C)

Site: elbereth.rutgers.edu
Command line: <CRLF>

サイト: elbereth.rutgers.edu Commandは立ち並んでいます: <CRLF>。

Login       Name               TTY Idle    When            Office
rinehart Mark J. Rinehart      p0  1:11 Mon 12:15  019 Hill       x3166
greenfie Stephen J. Greenfiel  p1       Mon 15:46  542 Hill       x3074
rapatel  Rocky - Rakesh Patel  p3    4d Thu 00:58  028 Hill       x2287
pleasant Mel Pleasant          p4    3d Thu 21:32  019 Hill    908-932-
dphillip Dave Phillips         p5  021: Sun 18:24  265 Hill       x3792
dmk      David Katinsky        p6    2d Thu 14:11  028 Hill       x2492
cherniss Cary Cherniss         p7    5  Mon 15:42  127 Psychol    x2008
harnaga  Doug Harnaga          p8  2:01 Mon 10:15  055 Hill       x2351
brisco   Thomas P. Brisco      pe  2:09 Mon 13:37  h055           x2351
laidlaw  Angus Laidlaw         q0  1:55 Mon 11:26  E313C       648-5592
cje      Chris Jarocha-Ernst   q1    8  Mon 13:43  259 Hill       x2413

ログインName TTY Idle WhenオフィスrinehartマークJ.ラインハートp0 1: 月曜日の月曜日の12:15 019ヒルx3166 greenfieスティーブンJ.Greenfiel p1の11、15:46 542 ヒル・x3074 rapatelロッキー--快いRakeshパテルp3 4d木曜日の00:58の木曜日の21:32 019ヒル028ヒルx2287メルPleasant p4 3d908-932dphillipデーヴフィリップスp5 021: 127Psychol x2008 harnagaダグHarnaga p8 2: 265ヒルx3792 dmkデヴィッドKatinsky p6 2d14:11 028ヒルx2492 chernissケーリーCherniss p7 5月曜日の木曜日の18:24 15:42Sunの01月曜日の10:15 055ヒルx2351 briscoトーマスP.Brisco pe13:37h055 x2351 laidlawアンガスレイドローq0 1: 55日月曜日の11:26E月曜日の2:09 313C648-5592cjeなクリス・Jarocha-エルンスト、q1 8月曜日の13:43、259ヒルx2413

4.2.  Example with name specified ({U}{C})

4.2. 名前が指定されている例(u C)

Site: dimacs.rutgers.edu
Command line: pirmann<CRLF>

サイト: dimacs.rutgers.edu Commandは立ち並んでいます: pirmann<CRLF>。

Login name: pirmann                     In real life: David Pirmann
Office: 016 Hill, x2443                 Home phone: 989-8482
Directory: /dimacs/u1/pirmann           Shell: /bin/tcsh
Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.
No unread mail
Project:
Plan:
                      Work Schedule, Summer 1990
                 Rutgers LCSR Operations, 908-932-2443

ログイン名: pirmann In現実: デヴィッドPirmannオフィス: 016 ヒル、x2443ホーム電話: 989-8482ディレクトリ: /dimacs/u1/pirmannシェル: /bin/tcsh Lastは6月23日土曜日にログインします。10:47 romulus.rutgersからのttyp0に関して。 読まれていないメールProjectがありません: 以下を計画してください。 仕事スケジュール、1990年夏のラトガースのLCSR操作、908-932-2443

                        Monday       5pm - 12am
                        Tuesday      5pm - 12am
                        Wednesday    9am -  5pm
                        Thursday     9am -  5pm
                        Saturday     9am -  5pm

火曜日午後5時から午前12時水曜日午前9時から午後5時木曜日午前9時から午後5時土曜日午前9時から午後5時月曜日午後5時から午前12時

                           larf larf hoo hoo

larf larf hoo hoo

Zimmerman                                                      [Page 10]

RFC 1196                         Finger                    December 1990

ジンマーマン[10ページ]のRFCの1196年の指の1990年12月

4.3.  Example with ambiguous name specified ({U}{C})

4.3. あいまいな名前が指定されている例(u C)

Site: elbereth.rutgers.edu
Command line: ron<CRLF>
Login name: spinner                     In real life: Ron Spinner
Office: Ops Cubby,    x2443             Home phone: 463-7358
Directory: /u1/spinner                  Shell: /bin/tcsh
Last login Mon May  7 16:38 on ttyq7
Plan:
            ught i
          ca      n
        m           a
       '      ...     t
      I      .   .     i
             !         m
      !       !       e
       p       !pool
        l
         e
          H

サイト: elbereth.rutgers.edu Commandは立ち並んでいます: ron<CRLF>Loginは以下を命名します。 紡績工In現実: ロン紡績工オフィス: オプアートCubby、x2443ホーム電話: 463-7358ディレクトリ: /u1/spinnerシェル: /bin/tcsh Lastがログインする、ttyq7 Planの上の5月7日月曜日の16:38: ught私はn m a'…t I i!m!e pをcaします!l e Hをプールしてください'

Login name: surak                       In real life: Ron Surak
Office: 000 OMB Dou,    x9256
Directory: /u2/surak                    Shell: /bin/tcsh
Last login Fri Jul 27 09:55 on ttyq3
No Plan.

ログイン名: surak In現実: ロンSurakオフィス: 000 OMBのドウ、x9256ディレクトリ: /u2/surakシェル: /bin/tcsh Lastがログインする、ttyq3の上の7月27日金曜日の09:55、Planがありません。

Login name: etter                       In real life: Ron Etter
Directory: /u2/etter                    Shell: /bin/tcsh
Never logged in.
No Plan.

ログイン名: etter In現実: ロンEtterディレクトリ: /u2/etterシェル: /bin/tcsh、まさか、ログインしました。 プランがありません。

4.4.  Example of query type {Q2} ({U}{H}{H}{C})

4.4. 質問タイプQ2に関する例(u H、H、C)

Site: dimacs.rutgers.edu
Command line: hedrick@math.rutgers.edu@pilot.njin.net<CRLF>

サイト: dimacs.rutgers.edu Commandは立ち並んでいます: hedrick@math.rutgers.edu@pilot.njin.net<CRLF>。

[pilot.njin.net]
[math.rutgers.edu]
Login name: hedrick                     In real life: Charles Hedrick
Office: 484 Hill, x3088
Directory: /math/u2/hedrick             Shell: /bin/tcsh
Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge
No unread mail
No Plan.

[pilot.njin.net][math.rutgers.edu]ログイン名: hedrick In現実: チャールズヘドリックオフィス: 484 ヒル、x3088ディレクトリ: /math/u2/hedrickシェル: 怪物-gw.rutgeから読まれていなくないttyp1の上の6月24日日曜日の00:08がPlanがないのに郵送する/bin/tcsh Lastログイン。

Zimmerman                                                      [Page 11]

RFC 1196                         Finger                    December 1990

ジンマーマン[11ページ]のRFCの1196年の指の1990年12月

5.  Acknowledgments

5. 承認

   Thanks to everyone in the Internet Engineering Task Force for their
   comments.  Special thanks to Steve Crocker for his security
   recommendations and prose.

彼らのコメントをインターネット・エンジニアリング・タスク・フォースの皆をありがとうございます。 彼のセキュリティ推薦と散文のためのスティーブ・クロッカーのおかげで、特別です。

6.  Security Considerations

6. セキュリティ問題

   Security issues are discussed in Section 3.

セクション3で安全保障問題について議論します。

7.  Author's Address

7. 作者のアドレス

   David Paul Zimmerman
   Center for Discrete Mathematics and
   Theoretical Computer Science
   Rutgers University
   P.O. Box 1179
   Piscataway, NJ 08855-1179

離散的な数学のためのデヴィッドポールジンマーマンセンターとP.O. Box1179ピスキャタウェイ、理論上のコンピュータサイエンスラトガース大学ニュージャージー08855-1179

   Phone: (908)932-4592

以下に電話をしてください。 (908)932-4592

   EMail: dpz@dimacs.rutgers.edu

メール: dpz@dimacs.rutgers.edu

Zimmerman                                                      [Page 12]

ジンマーマン[12ページ]