RFC 501 (rfc501) - Page 2 of 5

Un-muddling "free file transfer"

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


   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.

   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.

   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]

   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?).



Pogran