RFC 501 (rfc501) - Page 2 of 5
Un-muddling "free file transfer"
Alternative Format: Original Text Document
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