Bug 2092685

Summary: ftp client sent SYST before authentication if one specify -n option
Product: [Fedora] Fedora Reporter: masanari iida <masanari.iida>
Component: ftpAssignee: Michal Ruprich <mruprich>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 37CC: jaskalnik, jsynacek, mruprich
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description masanari iida 2022-06-02 04:19:28 UTC
Description of problem:
ftp client send SYST before user authentication if one specify -n option.
It causes ftp to select default file transfer type as ascii.

Version-Release number of selected component (if applicable):
ftp-0.17-88.fc35.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install OS and ftp client rpm.
2. Prepare FTP server. I use RHEL8 (vsftpd).
3. Connect ftp Server as follow

4. Actual results: (Bad case)

$ ftp -d -n 192.168.122.173
Connected to 192.168.122.173 (192.168.122.173).
220 (vsFTPd 3.0.3)
---> SYST                              <== 
530 Please login with USER and PASS.
ftp> user iida
---> USER iida
331 Please specify the password.
Password:
---> PASS XXXX
230 Login successful.
ftp> type
Using ascii mode to transfer files.
ftp>

Expected results: (Good case)

$ ftp -d 192.168.122.173
Connected to 192.168.122.173 (192.168.122.173).
220 (vsFTPd 3.0.3)
Name (192.168.122.173:iida): iida
---> USER iida
331 Please specify the password.
Password:
---> PASS XXXX
230 Login successful.
---> SYST                           <= SYST was sent after login
215 UNIX Type: L8
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> exit

Additional info:
In ftp source, the client check the SYST result.
If server sent "215 UNIX type: L8", ftp change the transfer mode 
to binary.

              printf("reply_string = %s\n",reply_string);  <= for debug
              if (!strncmp(reply_string, "215 UNIX Type: L8", 17)) {
                      if (proxy)
                              unix_proxy = 1;
                      else
                              unix_server = 1;
                       /*
                         * Set type to 0 (not specified by user),
                         * meaning binary by default, but don't bother
                         * telling server.  We can use binary
                         * for text files unless changed by the user.
                         */
                        type = 0;
                        (void) strcpy(typename, "binary");
                        if (overbose)
                            printf("Using %s mode to transfer files.\n",
                                typename);

But in case of -n case, 
ftp client sent SYST before login to the FTP server, 
so the server sent "530 Please login with USER and PASS."
It cause the reply_string is "530 Please login with User and Pass" 
instead of "215 UNIX Type: L8".

This symptom was initially found in ftp on RHEL7.
I have confirmed this symptom exist in ftp on FC35, which I use at home.
And upstream code also have this symptom.

Workaround
Specify file transfer type as "binary" before transfer the files.

Comment 1 Michal Ruprich 2022-06-03 09:25:58 UTC
Hi Masanari,

thanks for the bugreport. While I agree that ftp should not fall into ascii mode just because of the unexpected 530 answer, this might be a problem in vsftpd. I am trying this with proftpd and pure-ftpd and they both respond with correct answer.

pure-ftpd:
# ftp -d -n 10.0.139.33
Connected to 10.0.139.33 (10.0.139.33).
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 1 of 50 allowed.
220-Local time is now 05:17. Server port: 21.
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
---> SYST
215 UNIX Type: L8  <----------- correct IMO
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ---> QUIT
221-Goodbye. You uploaded 0 and downloaded 0 kbytes.
221 Logout.

#ftp -d 10.0.139.33
Connected to 10.0.139.33 (10.0.139.33).
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 1 of 50 allowed.
220-Local time is now 05:18. Server port: 21.
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
Name (10.0.139.33:mruprich): 
Login failed. <------- just pressed ctrl+D here
---> SYST
215 UNIX Type: L8 <-------------- Correct
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ---> QUIT
221-Goodbye. You uploaded 0 and downloaded 0 kbytes.
221 Logout.

proftpd:
# ftp -d 10.0.139.33
Connected to 10.0.139.33 (10.0.139.33).
220 FTP Server ready.
Name (10.0.139.33:mruprich): 
Login failed.
---> SYST
215 UNIX Type: L8 <-------------
Remote system type is UNIX.
Using binary mode to transfer files.

#ftp -d -n 10.0.139.33
Connected to 10.0.139.33 (10.0.139.33).
220 FTP Server ready.
---> SYST
215 UNIX Type: L8 <------------------
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ---> QUIT
221 Goodbye.

I am going to discuss this with my colleague that maintains vsfptd.

Comment 2 masanari iida 2022-06-03 09:35:32 UTC
FYI, the vsftpd that I used is vsftpd-3.0.3-34.el8.x86_64.

Comment 3 masanari iida 2022-06-03 09:49:14 UTC
Quick test with vsftpd-3.0.3-46.fc35.x86_64,
the test result is the same as vsftpd from RHEL8.

$ ftp -d -n 192.168.122.236
Connected to 192.168.122.236.
220 (vsFTPd 3.0.3)
---> SYST
530 Please login with USER and PASS.
ftp> user iida
---> USER iida
331 Please specify the password.
Password: 
---> PASS XXXX
230 Login successful.
ftp> type 
Using ascii mode to transfer files.
ftp>

Comment 4 Ben Cotton 2022-11-29 18:56:15 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.