Browse Prior Art Database

Two solutions to a file transfer access problem (RFC0505) Disclosure Number: IPCOM000005079D
Original Publication Date: 1973-Jun-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 3 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M.A. Padlipsky: AUTHOR

Related Documents

10.17487/RFC0505: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 45% of the total text.

Network Working Group M. A. Padlipsky Request for Comments: 505 MIT-Multics NIC: 16156 25 June 1973

Two Solutions to a File Transfer Access Problem

In RFC #87, Bob Bressler raises the issue of how one can use the File Transfer Protocol to send a file to a user on another system without knowing that user’s password. In RFC 501, Kan Pogran points out certain objections to Bressler’s solution of having a "daemon" process do the job -- in particular, the fact that it would require an interpretive access control mechanism in the daemon different from most system’s normal access control mechanisms. Because Ken felt that it would be too much of a digression in RFC 501 for him to cover the following points fully, I decided it might be of interest to deal with them separately: There are at least two solutions to the problem Bob raised in RFC 487 -- in regard to "my" sending "him" a file without knowing his password -- which don’t give rise to the problems noted in RFC 501. One hinges on adding a convention to the FTP, the other on adding a command.

The first solution is very straightforward. Instead of having me push the file, he could pull it. That is, he uses his own "principal identifies" (thus solving access permission problems at his end) and his own User FTP to extract the file with the aid of my Server FTP. All this requires is that 1) I give appropriate access permission on my end, and 2) he have the ability to use my Server FTP. The second condition is met by either a) his having an account on my system, or b) my system’s having a known account for "free" Server FTP use. (*)

So standing the model on its head solves the functional problem, although he has to pay for the User FTP. But, then, it’s he who wants the file, so why shouldn’t he? On the other hand, "he" might not be logged in right now and I might be -- and by the time he can get logged in my system might be scheduled to be down. Fortunately, there’s also a moderately straightforward solution to the problem as originally posed. This goes back to the mechanism used to prevent capricious and/or malicious card input on Multics: Instead of placing input (card deck or transferred file) directly into the alleged recipient’s directory, place it in a "pool" directory and merely inform the recipient of its arrival. If he really wanted it, he then copies it into his own directory. That way, unauthorized people can’t freeload on somebody else’s directory (and the pool is, of course, periodically purged), nor can they clobber others’ already- existing files.

Padlipsky [Page 1]

RFC 505 Two Solutions to a File Transfer 25 June 1973


This second solution has the virtue of requiring fewer steps than the first, and would work even when the first wouldn’t; so even though it would require another FTP command, I propose the addition of a new FTP "POOL" command, which does what the last paragraph described. Depending on the various Servers’ protection mechanisms, the pooled files could be made readable...