I'm currently having to use a very limited FTP client/adapter to upload some files to a remote server. I say limited, because the resulting files end up on the remote server with permissions 000 and there appears to be no way to configure what the permissions should be, unlike some other clients. (I know WinSCP can do this.)
I was told by a colleague that FTP was completely agnostic with regards to file permissions, and simply transfers the file data. Assuming this is correct, how does a client such as WinSCP set the permissions of the file on the remote server? It was suggested to me that the client is likely executing a chmod via SSH i.e. setting the permissions after the fact.
Best Answer
Your colleague is right, in the sense that October 1985's RFC 959 doesn't seem to provide a command specifically designed for permission changes. RFC 959 does provide specifications of commands to upload files (RFC 959 page 30 has the “STOR” command to store files), download files (page 30 has the “RETR” command to retrieve files), and optional extensions like MKD (make directory) and RMD (remove directory). The RFC notes, "It is the prerogative of a server-FTP process to invoke access" "controls." (However, from my reading of the RFC, I believe that the "access controls" being referred to are more about supporting the ability to log in with a username, and not intending to refer to the idea of using FTP to change the permissions of files.)
RFC 959 page 47 contains a list of the commands that are built into the FTP specification of RFC 959. For a while, I was wondering making an FTP server for a specific platform, and I've read through each of those commands. I've also glanced through IANA “FTP Commands and Extensions” registry, which is referred to by March 2010's RFC 5797. I don't recall any of those commands providing a way to be changing permissions, except one:
RFC 959 page 33 has the “SITE” command. (Some FTP clients have a local command called “QUOT” or “quote”, which ends up sending a SITE command to the FTP server.) Basically, the standard of the SITE command is that text is sent to the FTP server, and the FTP server decides what to do with it. Usage of this command can do things like change file permissions, search a site for files, or reboot the FTP server. In theory, sending the command “HELP SITE” will show details of some functionality provided through the site command. RFC 959 page 33 even specifies this:
The challenge to this theory is just that the “HELP SITE” command actually results in showing text from the FTP server, and incomplete documentation might not actually document every single possibility available.
Based on Jonathan Leffler's answer to knoti99's question about “chmod syntax in FTP”, we can see that classic “ncftp” program did use the “SITE CHMOD” command to implement ncftp's “chmod” command, and that this feature wasn't supported by all FTP servers.
One more side note as I complete the FTP portion of this answer: FTP is very sniffable. Basically, what I mean by that is that FTP performs actions using "clear text". If you use "packet sniffing" ("packet capturing") software like tcpdump or Wireshark, you can see what happens with FTP. If you try transferring a file which is a small text file, and see what network traffic happens, the results will likely be pretty easy to comprehend. Using such an approach, you could change permissions and see what commands the software is actually using. I know this may be a bit more time-consuming to set up, which is why this answer provided many easier-to-obtain details, but knowing about this process could be helpful if you start to wonder any other details about what happens during FTP communications.
(I've edited this answer to add a response to another part of the question.)
I think that's a nice guess, although I don't think that's accurate when it comes to FTP. Actually, that guess is probably accurately describing the precise process that is used whenever the SFTP and SCP protocols are used. Since both of those protocols are based on SSH, the "chmod" command may be sent using the same SSH connection that is used as the rest of the encrypted connection. From my reading of those protocols, I do believe that this actually is exactly how file permissions typically get set when using SFTP (and SCP if that also supports setting the file permissions).
However, the way that this is typically handled with the FTP protocol is a quite different story, as I just described earlier. If you're using the FTP protocol, which is plaintext, then it is technically possible but rather unlikely that SSH is being used to follow up. (If software is capable enough to support SSH, then it generally also supports SFTP or SCP or both. As a result, support of the old FTP protocol is usually designed so that the complexity of encrypted communications won't be used as part of the process.)