Comment 19 for bug 2069324

Hi,
first of all thanks for all the prep work.
The patch LGTM and I agree we should add it.
I was happy to see the suggestions on how to reproduce, but while writing it out in more detail could not reproduce the hang. The following are the steps I drafted to an SRU templates "how to test and verify" steps. But the hang does not occur. Could you have a look where my steps diverge from what you had in mind?

# Install ftp server
$ sudo apt install vsftpd

# set a user with password, I use ubuntu:ubuntu in the examples here
$ passwd ubuntu

# add testfile to the users home dir
$ echo foobar > /home/ubuntu/egal

# Check with FTP if the normal setup works
root@o:~# ftp 127.0.0.1
Connected to 127.0.0.1.
220 (vsFTPd 3.0.5)
Name (127.0.0.1:root): ubuntu
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
229 Entering Extended Passive Mode (|||47570|)
150 Here comes the directory listing.
-rw-r--r-- 1 0 0 7 Jul 12 06:59 egal
226 Directory send OK.
ftp> get egal
local: egal remote: egal
229 Entering Extended Passive Mode (|||21047|)
150 Opening BINARY mode data connection for egal (7 bytes).
100% |**************************************************************************************************************************************************| 7 45.87 KiB/s 00:00 ETA
226 Transfer complete.
7 bytes received in 00:00 (8.49 KiB/s)
ftp> ^D
221 Goodbye.
root@o:~# cat egal
foobar
root@o:~# rm egal

# Now set up the failure condition
#1 add a few exec commands on pam
$ echo "account optional pam_exec.so debug quiet /bin/true" | sudo tee -a /etc/pam.d/vsftpd

# Restart server to be sure to pick up everything
$ sudo systemctl restart vsftpd.service

# Log in again to see the hang
$ ftp 127.0.0.1

^^ but this does not fall into the hang, I can get the file and quit normally.

It is not that the setup is totally useless, in /var/log/auth.log I see on the login
2024-07-12T07:27:01.030634+00:00 o vsftpd: pam_exec(vsftpd:account): Calling /bin/true ...

Do you have an advice what you do different to reproduce the issue?

P.S. along evaluating this I found many more changes we should apply to our ftp servers. Not all suitable for SRUs, but going forward I want to still improve them. To find the required time for that effort I internally filed SD-1755 to not fall through the cracks forever.