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
