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 nature of these services and the
specification of their syntax can be stated in a reply to
the HELP SITE command.”
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.)
It was suggested to me that the client is likely executing a chmod via SSH i.e. setting the permissions after the fact.
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.)
2It doesn't have anything to do with SSH. There simply is a CHMOD FTP command available. Aside from that most FTP servers support setting a default mode for newly created files. – Seth – 2017-01-31T12:53:01.163
1Just as an FYI... Typically for FTP exchanges, you merely connect to the server/FTP mailbox with the client, and then upload to the applicable upload directory. If you have permission the upload complete if not you are denied access, etc. The client "typically" won't need to set permissions and especially with WinSCP -- at least I've never had to do this with WinSCP for hundreds of FTP exchanges I maintain and support which are automated. Once the files make it to the FTP server, the client job is complete. Let the receiver or FTP admins deal with the server permissions otherwise. – Pimp Juice IT – 2017-01-31T13:12:17.933
@Seth: As you made your comment before my answer was posted, I kindly point out to you that the "CHMOD" FTP command is not actually a part of the file transfer protocol, despite the fact that multiple FTP client software products may seem to support such a command. (I discuss this further in my answer.) – TOOGAM – 2017-01-31T13:35:48.070
1@Walmart What are these "hundreds of FTP exchanges"? Sites exchanging data that get distributed publicly? I think lots of people use FTP to upload HTML content, and then want to change permissions so that files become accessible to the general public. It's a very insecure practice which I don't recommend (usage of SFTP / SCP / HTTPS would be preferred), but I believe this practice is still taught widely (unfortunately). I simply suggest that there may be different "usage case" scenarios where such features may be used more heavily than other scenarios. – TOOGAM – 2017-01-31T13:39:20.680
@TOOGAM thanks for pointing it out, your answer is interesting to read! Still as it's a SITE command it would be an FTP command (implementation depending on the server software) and SSH would not be involved (what I was really aiming at). Right now (with your information in mind) I'd assume that the FTP server is configured badly or that some other process is interfering. – Seth – 2017-01-31T13:49:27.060
@TOOGAM Ah... I didn't think about it in that context but it certainly makes sense and unfortunately I too have had to setup such a configuration to allow FTP access to a "test" IIS directory on an IIS Server once to allow developers to make changes to the test site on the production server OS (separate test and prod sites on the same OS). Also the hundred of automated jobs are not publicly accessible for the most part for what I was talking about by the way but what you added clarifies and makes sense. +1 on your answer. – Pimp Juice IT – 2017-01-31T14:46:33.477
An FTP client can't possibly set file attributes on a server. In fact, it can't do anything to the server, other than request that the server do things for it. (Assuming it doesn't exploit bugs in the server.) – David Richerby – 2017-01-31T16:32:02.640
1Are you actually using sftp, as tagged? sftp is a completely different protocol than ftp or ftps. The answer for ftp or ftps will be different than the answer for sftp. If you are not using sftp, the tag should be removed. – Wayne Conrad – 2017-01-31T20:25:24.240
@WayneConrad The question isn't really about my problem, I'm limited in my options. Rather, I suppose I wanted to know what mechanisms are available for FTP etc. given that I know of at least one client that can configure permissions. WinSCP supports SFTP and SCP, so at least that tag should stay. – Scott Oliver – 2017-02-01T13:08:44.017
If the tag should stay, then the question is overly broad. A separate question should be asked for sftp. – Wayne Conrad – 2017-02-01T16:49:09.160