** Description changed: + [ Impact ] + + * when running sub-processes on login through pam_exec a process + is spawned. That can confuse vsftp if that child ends triggering SIGCHLD but + already been picke dup by e.g. pam_exec.so itself. + + * The fix uses waitpid over wait to be able to pass options. With that + it sets WNOHANG when calling vsf_sysutil_wait is called from common_do_login + (as there pam_exec would run if configured). That allows it to + "return immediately if no child has exited" [1] + + [1]: https://manpages.ubuntu.com/manpages/noble/en/man2/wait.2.html + + [ Test Plan ] + + # install + $ apt install lftp vsftpd + # change config + $ sed -i.old '1 i\account optional pam_exec.so debug quiet /root/foo.sh\' /etc/pam.d/vsftpd + # script to run + $ cat > /root/foo.sh << EOF + #!/bin/bash + /bin/true + touch /tmp/brooks-was-here + /bin/true + EOF + $ chmod +x /root/foo.sh + # enable ssl + $ sed -i -s -e 's/ssl_enable=NO/ssl_enable=YES/' /etc/vsftpd.conf + $ systemctl restart vsftpd.service + # Place a file there + $ echo foobar > /home/ubuntu/egal + # set test PW to ubuntu user + echo 'ubuntu:ubuntu' | chpasswd + + # Using it with ftps (and ignore cert verification as it is the snakeoil + cert) + + To verify the test config, if you run this in a second console you should see it calling the script as yo uact on the server. + $ tail -f /var/log/auth.log + ... + 2024-07-16T07:30:37.966553+00:00 o vsftpd: pam_exec(vsftpd:account): Calling /root/foo.sh ... + + Good case (Noble / Oracular): + + root@n:~# lftp 127.0.0.1 + lftp 127.0.0.1:~> set ftp:ssl-force true + lftp 127.0.0.1:~> set ssl:verify-certificate false + lftp 127.0.0.1:~> login ubuntu ubuntu + lftp ubuntu@127.0.0.1:~> dir + -rw-r--r-- 1 0 0 7 Jul 16 07:30 egal + lftp ubuntu@127.0.0.1:~> get egal + 7 bytes transferred + lftp ubuntu@127.0.0.1:~> + exit + root@n:~# cat egal + foobar + + Bad case (Focal and Jammy) + root@j:~# lftp 127.0.0.1 + lftp 127.0.0.1:~> set ftp:ssl-force true + lftp 127.0.0.1:~> set ssl:verify-certificate false + lftp 127.0.0.1:~> login ubuntu ubuntu + lftp ubuntu@127.0.0.1:~> dir + `ls' at 0 [Sending commands...] + + [ Where problems could occur ] + + * This changes signal handling for SIGCHLD. + The code now returns cleanly if there was nobody to wait for, which formerly + would have caused a the main process to die "Child died, so we'll do the same" + That is intentionally changed for the condition of the child already being + consumed. + If there is a use case of the child leaving which was meant to terminate + (unlikely, this is an unclean die call) it might no more happen now. + + [ Other Info ] + + * The code is the same (only no change rebuilds) still, this does not occur in + Noble and Oracular. At least not with the current test setup. That is slightly + disturbing. + Also in the reproduction we've seen that it only occurred with FTPS, but that + is not conceptually tied to the problem, it might only be yet another detail + that changes the timing and size of the signal race window. + Of course we can assume that it is just a race and the window is + different there, but then should we not fix it? Or we can assume something + else e.g. pam_exec has changed behavior to mask the issue and hence no vsftpd + change is needed there. I think it is wasted to research this for ages, but + it leaves some uncertainty. + + + --- + When you try to run a script with pam_exec.so on login vsftpd freezes with SIGCHLD. This was fixed in 2015 by redhat and never adopted to Debian/Ubunutu. See also: - https://bugzilla.redhat.com/show_bug.cgi?id=1198259 - https://git.centos.org/rpms/vsftpd/blob/54ac5fac29fcc1bb68f2e96e63ecfda655286ff8/f/SOURCES/0026-Prevent-hanging-in-SIGCHLD-handler.patch
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2069324 Title: vsftpd hangs with SIGCHLD when pam_exec.so is used To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/2069324/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
