RFC501 日本語訳

Network Working Group                                          K. Pogran
Request for Comments: 501                                    MIT-Multics
NIC: 15718                                                   11 May 1973

Pogranがコメントのために要求するワーキンググループK.をネットワークでつないでください: 501MIT-Multics NIC: 15718 1973年5月11日

                    Un-Muddling "Free File Transfer"

不-混乱状態「無料のファイル転送」

   As the ARPA Network begin to mature, we find ourselves addressing
   issues and concepts deliberately put off and left untouched at
   earlier stages of Network development.  Among the issues now coming
   to the fore are access control, user authentication, and accounting.
   These issues arise immediately out of efforts to develop uniform
   methods for providing limited "free" access to the File Transfer
   Servers of the host systems, to meet user needs for mail transmission
   and similar services.

ARPA Networkが熟し始めるとき、私たちは気付くと故意に延期されて、Network開発の早期のステージにおいて触れない状態で残っている問題と概念を扱っています。 問題の中では、もう表立って来るのは、アクセスコントロール、ユーザー認証であり、説明されています。 これらの問題は、メール送信と同様のサービスのユーザ需要を満たすためにホストシステムのFile Transfer Serversへの限られた「自由な」アクセスを提供するための一定のメソッドを開発するためにすぐ取り組みから起こります。

   Several proposals have been made, described by such phrases as
   "login-less mail", "'free' accounts", "free file transfer", etc.
   These proposals inevitably have imbedded in them some particular
   notion of how such things as access control and user authentication
   are accomplished and these proposals, which knowingly or unknowingly
   make presumptions about the implementation of such mechanisms,
   inevitably meet with strong criticism from implementors whose
   systems' mechanisms are quite different.

「ログインなしのメール」、「'自由な'アカウント」、「無料のファイル転送」などのような句によって説明されて、いくつかの提案をしました。 これらの提案はそれらで必然的にコントロールとユーザー認証にアクセスするようなものがどう優れるかに関する何らかの特定の概念を埋め込みました、そして、これらの提案(そのようなメカニズムの実装に関して推定を故意にか知らずにする)は激しい批判で作成者からだれのものに必然的に会います。システムのメカニズムは全く異なっています。

   In RFC 467, Bob Bressler proposes ways of helping out users who wish
   to transfer files to or from "systems which have some flavor of
   security, but on which the user has no access privileges".
   Unfortunately, beginning with the first paragraph of the RFC, the
   notions of access controls on files (examples of protection
   mechanisms), and control of access to the system (user
   authentication) are thoroughly muddled.  In addition, he makes
   sweeping assumptions about the nature and use of accounting
   mechanisms and accounts at server sites.  RFC 487 also has buried
   deep within it assumptions about the nature of the access control and
   user authentication aspects of File Transfer Server implementations.

RFC467では、ボブBresslerはシステムか「セキュリティの何らかの風味を持っていますが、ユーザがアクセス権は全く持っていないシステム」からファイルを移したがっているユーザを助ける方法を提案します。 残念ながら、RFCの第一節で始まるファイルの上のアクセス制御の概念(保護メカニズムに関する例)、およびシステムへのアクセスのコントロール(ユーザー認証)は徹底的に混乱します。 さらに、彼はサーバサイトで会計の自然と使用に関する大ざっぱな推定をメカニズムとアカウントにします。 RFC487もアクセス制御の本質とFile Transfer Server実装のユーザー認証局面に関する仮定をそれの中で深く埋めました。

   What's needed at this juncture, of course, is a lucid discussion of
   the general concepts involved in protection mechanisms, and file
   system access controls in particular.  Well, you won't find that in
   the remainder of this RFC.  What you will find is perhaps enough of a
   discussion to un-muddle that which RFC 487 has muddled; the rest will
   have to come down the pike at a later time.

この際もちろん必要であるものは特に保護メカニズム、およびファイルシステムアクセス制御にかかわる一般概念の明快な議論です。 さて、あなたはこのRFCの残りでそれを見つけないでしょう。 あなたが見つけるものは恐らく不-RFC487が混乱させたそれを混乱させる議論に十分です。 残りは後で現れなければならないでしょう。

   In many systems, mechanisms which control access to the system,
   mechanism which control access to files, and accounting mechanisms
   all mesh at the moment at which a prospective user of the system is
   authenticated: the system has checked his user-name, password,

多くのシステムで、制御されるメカニズムはシステム、すべてがシステムの将来のユーザが認証される瞬間にファイル、および会計機構へのそれのコントロールアクセスを網の目にかけるメカニズムに以下にアクセスします。 システムは彼のユーザ名、パスワードをチェックしました。

Pogran                                                          [Page 1]

RFC 501             Un-Muddling "Free File Transfer"         11 May 1973

Pogran[1ページ]RFC501不-混乱状態「無料のファイル転送」1973年5月11日

   account, or whatever, and decided that he is, indeed, a valid user of
   the system.  This user, who would like to have some information
   processing performed on his behalf, is termed a principal in "privacy
   and protection" parlance.  Some number of processes are initially set
   up for this principal, and some (presumably unforgeable) principal
   identifier is associated with the process(es), so that their requests
   for access to files and other system resources may be properly
   validated.  In addition, the identify of the account to be charged
   for the resources consumed by these processes is associated with the
   processes at this time [1], although on some systems, a process may
   change its account identifier at any time.

何でもに説明して、本当に、彼がシステムの正規ユーザーであると決めました。 このユーザ(彼の代理に何らかの情報処理を実行して頂きたい)は「プライバシーと保護」話法で元本と呼ばれます。 何らかの数のプロセスが初めはこの主体に設定されます、そして、何らかの(おそらく非鍛造可能)の主要な識別子がプロセス(es)に関連しています、適切にファイルと他のシステム資源へのアクセスを求める彼らの要求を有効にすることができるように。 課金されて、これらのプロセスによって消費されたリソースがプロセスに関連づけられるということであることをアカウントを特定してください。さらに、[1] いくつかのシステムの上で変えますが、このとき、プロセスはいつでも、口座名を変えてもよいです。

   The first question is: Whose principal identifier does a File
   Transfer Server process use? There are at least two possibilities: 1)
   the File Transfer Server can run as a "system daemon" process, with
   (usually) a highly privileged principal identifier.  When acting on
   behalf of a user, it must, itself, interpretively evaluate that
   user's access to a desired file.  Also, it must be able to charge
   that user's account for the resources it uses.  2) A File Transfer
   Server process can be given the user's own principal identifier.
   With this implementation, validation of the user's access to files is
   performed automatically by the usual file system mechanisms.

最初の質問は以下の通りです。 File Transfer Serverプロセスはだれの主要な識別子を使用しますか? 少なくとも2つの可能性があります: 1) File Transfer Serverは(通常)非常に特権がある主要な識別子と共に「システムデーモン」プロセスとして稼働できます。 ユーザを代表して行動するときそれ、必須(それ自体)は解釈的に必要なファイルへのそのユーザのアクセスを評価します。 また、それは使用するリソースのためにそのユーザの勘定を請求できなければなりません。 2) ユーザの自己の主要な識別子をFile Transfer Serverプロセスに与えることができます。 この実装で、ファイルへのユーザのアクセスの合法化は自動的に実行されて、普通がシステム機構をファイルするということです。

   Paragraph four of RFC 487 clearly presumes implementation 1): "If a
   user connects to an FTP server and makes a file request without
   supplying a user name-password, the server should then examine the
   file access parameters ..." Systems truly concerned about protection
   may prefer implementation 2), and for good reason -- it follows the
   "principle of least privilege", which states that a process should
   execute with as little access privilege as it requires to perform its
   tasks properly.  Running a File Transfer Server process with a user's
   principal identifier rather than with that of a system daemon leaves
   the system far less susceptible to damage caused by incorrect actions
   of the File Transfer Server. [2]

RFC487のパラグラフfourは、実装1)であると明確に推定します: 「そして、ユーザがユーザ名前パスワードを提供しないでFTPサーバに接続して、ファイル要求をするなら、サーバはファイルアクセスパラメタを調べるべきです」… 永遠に、推論してください--本当に保護に関して心配しているシステムは実装2)を好むかもしれません、そして、それは「最少の特権の原則」に続きます。それとしての特権は適切にタスクを実行するのをプロセスが同じくらい少ないアクセスで実行するはずであるその州を必要とします。 システムデーモンのものでというよりむしろユーザの主要な識別子でFile Transfer Serverプロセスを実行すると、システムはFile Transfer Serverの不正確な機能でもたらされた損害にはるかに影響されやすくないおかれます。[2]

   The next question is: Whom do you charge for file transfers? Bressler
   tries to set down some guidelines for determining who to charge for
   "non-logged-in" (read: "free") file transfer usage: "Clearly, storing
   a file in a user's directory can be charged to that user." How is the
   word "storing" used here? Surely, "that user" can be billed for the
   disk or other storage medium charges incurred by that file which is
   now taking up space, but is it legitimate to charge "that user" for
   the I/O and/or CPU resources used by someone else to transfer a file
   over the Network, and place it into that user's directory? For
   example, should the recipient of Network mail be charged for the
   resources consumed by someone else in sending it? (Would you care to
   pay the postage for all the junk mail that arrives in your home (U.S.
   Mail) mailbox?).

次の質問は以下の通りです。 あなたはファイル転送のためにだれを請求しますか? Bresslerは「非ログインされた」(「自由な」状態で以下を読む)ファイル転送用法のためにだれを請求するかを決定するためのいくつかのガイドラインを置こうとします: 「明確に、ユーザのディレクトリのファイルを保存するのをそのユーザに請求できます。」 「保存」という言葉はここでどのように使用されますか? 確実に、充電が現在場所を取っているそのファイルで被ったディスクか他の記憶媒体のために「そのユーザ」を請求できますが、「そのユーザ」を請求するために、他の誰かによる入出力、そして/または、CPU運用資金がNetworkの上にファイルを移して、そのユーザのディレクトリにそれを置くのは、正統ですか? 例えば、Networkメールの受取人はそれを送る際に他の誰かによって消費されたリソースのために請求されるべきですか? (あなたのホーム(米国メール)メールボックスに到着するすべてのダイレクトメールの送料を支払いたいですか?)?

Pogran                                                          [Page 2]

RFC 501             Un-Muddling "Free File Transfer"         11 May 1973

Pogran[2ページ]RFC501不-混乱状態「無料のファイル転送」1973年5月11日

   Over the telephone, Bob explained to me that he desired a mechanism
   which would, for example, enable me, at his request, to transfer a
   file from my system to his directory on his system, without requiring
   that I know his password.  All well and good.  In this situation, it
   would make sense to charge Bressler's account for this file transfer.
   But how does an un-authenticated user tell a server "Charge this to
   Bressler's account because he says it's OK"? Pitfalls abound.  The
   file Transfer Server process needs to be able to charge an arbitrary
   user's account; this again presupposes implementation 1) of the File
   Transfer Server described above (or else any user process in the
   system would have the capability of charging any user's account; this
   seems undesirable).  A more reasonable approach would be to charge
   that instance of the File Transfer Server process to a general
   "Network services" account.  Mechanisms for accomplishing this are
   presented in RFC 491. [3]

電話の上では、ボブは、彼が例えば私を可能にするメカニズムを望んでいたと私に説明しました、彼のシステムの上で私のシステムから彼のディレクトリまでファイルを移すという私が彼のパスワードを知るのが必要であることのない彼の要求によって。 すべて良くて、良いです。 この状況で、それはこのファイル転送のための充電Bresslerのアカウントに理解できるでしょう。 しかし、不-認証されたユーザは、サーバがどのように「彼が、それがOKであると言うので、Bresslerのアカウントにこれを請求する」と言いますか? 落とし穴は富みます。 ファイルTransfer Serverプロセスは、任意のユーザの勘定を請求できる必要があります。 これは再びFile Transfer Serverの1つが)上で説明した実装を予想します。(または、システムのどんなユーザ・プロセスにも、どんなユーザの勘定も請求する能力があるでしょう。 これが望ましくなく思える、) より合理的なアプローチは一般的な「ネットワーク・サービス」アカウントにFile Transfer Serverプロセスのそのインスタンスを請求するだろうことです。 これを達成するためのメカニズムはRFC491に提示されます。 [3]

   RFC 487 matter-of-factly suggests that retrieval of files in "system"
   directories should be charged to "overhead".  Here too, some broad
   assumptions are made about the nature of accounting mechanisms and
   accounts at server sites.  In addition, an undesirable loss of
   generality is imposed upon the File Transfer Server: It is now
   required to have the capability of distinguishing the pathnames of
   "system" files from those of "user" files.  In a number of systems,
   there is no syntactic distinction between the two, and the same
   general mechanisms can be used to manipulate both kinds of files (if
   a distinction between them can be made at all).  The addition of code
   to the File Transfer Server which examines the pathname given for
   each request, to determine which sort it is, seems to be antithetical
   to the goals of uniformity and generality that many of today's
   systems have achieved.

RFC487は、「システム」ディレクトリにおける、ファイルの検索が「オーバーヘッド」に請求されるべきであると淡々と示唆します。 また、ここで、いくつかの広い仮定がサーバサイトで会計機構とアカウントの本質に関してされます。 さらに、望ましくない一般性の喪失はFile Transfer Serverに課されます: それが、現在、「ユーザ」ファイルのものからの「システム」ファイルのパス名を区別する能力を持つのに必要です。 多くのシステムには、2つの間には、どんな構文の区別もありません、そして、両方の種類のファイルを操作するのに同じ一般的機構は使用できます(それらの区別を少しでもすることができるなら)。 それがどの種類であるかを決定するという各要求のために与えられたパス名を調べるFile Transfer Serverへのコードの追加は今日のシステムの多くが実現した一様性と一般性の目標に対照的であるように思えます。

   The statement that a Network user's file transfer activity can be
   charged to a system-wide "overhead" account contains two assumptions:
   Such an account cannot be presumed to exist on all systems;
   furthermore, if it does exist, in some cases it just isn't the right
   account to charge.  Certainly, a good case can be made that the cost
   of fostering inter-user communication within the ARPA Network
   community (which is what "free" file transfer amounts to) should be
   borne by ARPA, meaning that such activity should be charged to ARPA-
   funded accounts.  If a host system's operation is entirely funded by
   ARPA (or if its management doesn't care who pays for this activity),
   then it makes sense to charge "free" file transfer activity to a
   "system overhead" account.  On the other hand, that isn't the correct
   course of action for a host system whose operation is not funded by
   ARPA, for charging "free" file transfers to "system overhead" would
   result in passing the cost along to local customers who may have no
   interest at all in the ARPA Network.

システム全体の「頭上」のアカウントにNetworkユーザのファイル転送活動を請求できるという声明は2つの仮定を含んでいます: そのようなアカウントはあえてすべてのシステムの上に存在できません。 存在しているなら、いくつかの場合、その上、それは単に請求する正しい勘定ではありません。 確かに、そのそのようなものを意味して、アーパネット共同体(「自由な」ファイル転送が達することである)の中のコミュニケーションがARPAによって持たれているはずである相互ユーザ活動を伸ばす費用がARPAへアカウントに資金を供給したと宣言されるべきである良い弁護はすることができます。 ホストシステムの操作がARPAによって完全に資金を供給されるなら(経営者側が、だれがこの活動の代価を払うかを気にかけないなら)、それは「自由な」ファイル転送活動を「システムオーバーヘッド」アカウントに請求する意味になります。 他方では、それは操作がARPAによって資金を供給されないホストシステムのための動作の正しい方針ではありません、「システムオーバーヘッド」への「自由な」ファイル転送がアーパネットで関心を全く持っていないかもしれない地元の顧客に費用を回すのに結果として生じると宣言するために。

Pogran                                                          [Page 3]

RFC 501             Un-Muddling "Free File Transfer"         11 May 1973

Pogran[3ページ]RFC501不-混乱状態「無料のファイル転送」1973年5月11日

   Lastly, Bressler suggests that for file retrieval, CPU charges "may
   be sufficiently small to not cause a major problem".  To believe this
   is naivete.  It may appear to be true for a system which doesn't
   charge the user for time spent executing supervisor code, or I/O
   routines, where Network software overhead doesn't show up in the
   user's bill.  In this case, Network software overhead must contribute
   to "general system overhead", the cost of which must be borne by all
   users.  I don't think many people in the Network community would
   consider the actual (as opposed to charged) CPU time spent
   transferring a file to be negligible.  Certainly, if a system is a
   very popular or busy one from a Network standpoint, the cumulative
   CPU time spent on "free" file transfers, viewed at the end of an
   accounting period (a week? a month? a year?) will not be negligible!

最後に、Bresslerは、ファイル検索に、CPU充電が「大した問題を引き起こすことができないくらい小さいかもしれないこと」を勧めます。 これを信じるのは、無邪気です。 それは監督コードを実行しながら費やされた時間のユーザを請求しないシステム、または入出力ルーチンに本当であるように見えるかもしれません。(そこでは、Networkソフトウェアオーバーヘッドがユーザの請求書に現れません)。 この場合、Networkソフトウェアオーバーヘッドは「一般的なシステムオーバーヘッド」に貢献しなければなりません。すべてのユーザがその費用を負担しなければなりません。 私は、Network共同体の多くの人々が、ファイルを移しながら費やされた実際(請求にされると対照的に)のCPU時間が取るにたらないと考えると思いません。 確かに、会計年度(1週間--1カ月--1年?)の終わりに見られた「自由な」ファイル転送に費やされた累積しているCPU時間はシステムがNetwork見地からの非常にポピュラーであるか忙しいものであるなら取るにたらなくならないでしょう!

   In this RFC, I've picked apart Bob Bressler's RFC 487, mostly because
   of its confusion of several distinct (although related) issues, and
   the implementation assumptions it contains which conflict with (or
   badly bend out of shape) mechanisms and design philosophies existing
   on other systems (in particular, the system I am most familiar with,
   Multics) [4].  The applicability of the discussions in this RFC, I
   think goes beyond that: We've got to acknowledge that it's difficult
   to propose Network-wide mechanisms for providing desirable services
   without building in assumptions about how they are to be implemented.
   We're at a point where we're asking for fairly sophisticated
   services, and proposing correspondingly sophisticated mechanisms.
   It's time to begin talking about how various systems accomplish such
   things as user authentication, access control, and so on, so that we
   can all gain a clearer understanding of such issues, and be able to
   propose mechanisms with fewer implementation assumptions built into
   them.

このRFCでは、私はほとんどいくつかの異なった(関係づけられますが)問題、メカニズムと衝突する(ひどく形が崩れていた状態で曲がってください)それが含む実装仮定、および他のシステム(事項、私が最も詳しいシステムのMultics)[4]に存在する設計理念の混乱のためにボブBresslerのRFC487をばらばらにしました。 これでの議論の適用性はそれを越えますRFC、Iが、思う: 私たちは、それらがどう実装されることになっているかに関する仮定で建てないで望ましいサービスを提供するためにNetwork全体のメカニズムを提案するのが難しいと認めなければなりません。 私たちは洗練されたサービスを公正に求めて、対応する精巧なメカニズムを提案しているところにポイントでいます。様々なシステムがどうユーザー認証のようなもの、アクセスコントロールなどを実行するかに関して話し始める時間です、私たちがそのような問題の、より明確な理解をすべて獲得して、それらが組み込まれたより少ない実装仮定でメカニズムを提案できるように。

   END NOTES:

音を終わらせてください:

   [1] On some systems, there is a one-to-one correspondence between
   principals and accounts.

[1] いくつかのシステムの上に、主体とアカウントとの1〜1つの通信があります。

   [2] It should be noted that systems which choose implementation 2)
   may require a user authentication sequence (USER, PASS, and possibly
   ACCT commands) before permitting any file transfers, as explicitly
   stated on page 17 of RFC 354 (NIC 10596), and page 20 of RFC 4554
   (NIC 14333).  This authentication sequence would be required to
   ascertain the principal identifier to be associated with the newly-
   spawned File Transfer Server process; the process is not allowed to
   proceed until its principal identifier has been established.

[2] どんなファイル転送も可能にする前に実装2)を選ぶシステムがユーザー認証系列(USER、PASS、およびことによるとACCTコマンド)を必要とするかもしれないことに注意されるべきです、17RFCページ(NIC10596)354、および20RFCページ(NIC14333)4554に明らかに述べられているように。 この認証系列が主要な識別子が新たに量産されたFile Transfer Serverプロセスに関連しているのを確かめるのに必要でしょう。 主要な識別子が確立されるまで、プロセスは続くことができません。

Pogran                                                          [Page 4]

RFC 501             Un-Muddling "Free File Transfer"         11 May 1973

Pogran[4ページ]RFC501不-混乱状態「無料のファイル転送」1973年5月11日

   [3] Note that there are at least two scenarios for accomplishing the
   transfer Bressler desires: Either I "push" the file, using my "User
   FTP" and his system's "FTP Server", or he "pulls" the file, using his
   "User FTP" and my system's "FTP Server".  Bob chose the first
   scenario; it can be argued that, since it is Bob who wanted the file
   transferred, the second scenario is the more appropriate one.  A
   forthcoming RFC by Mike Padlipsky expands on these points, as well as
   an entirely different alternative.

[3] 転送Bressler願望を達成するための少なくとも2つのシナリオがあることに注意してください: 私の「ユーザFTP」と彼のシステムの「FTPサーバ」を使用して、私がファイルを「押す」か、または彼はファイルを「引きます」、彼の「ユーザFTP」と私のシステムの「FTPサーバ」を使用して。 ボブは最初のシナリオを選びました。 2番目のシナリオがファイルを移して欲しかったのが、ボブであるので適切なものであると主張できます。 マイクPadlipskyによる今度のRFCは完全に異なった代替手段と同様にこれらのポイントについて詳述します。

   [4] Padlipsky keeps insisting that I've also shown the superiority of
   implementation 2) of the File Transfer Server (described above), but
   I resist that conclusion.  Those interested may want to look at his
   Unified User-Level Protocol specification, which is based on a
   similar premise.

[4] Padlipskyはまた、私がFile Transfer Server(上で、説明される)の実装2)の優越を示したと主張し続けますが、私はその結論に抵抗します。 興味を持っているものは彼のUnified User-レベルプロトコル仕様を見たがっているかもしれません。(それは、同様の前提に基づいています)。

       [ This RFC was put into machine readable form for entry ]
              [ into the online RFC archives by Via Genie]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Via GenieによるオンラインRFCアーカイブへの]

Pogran                                                          [Page 5]

Pogran[5ページ]