| 2024-06-13 14:48:58 |
Markus Wigge |
bug |
|
|
added bug |
| 2024-06-13 14:48:58 |
Markus Wigge |
attachment added |
|
Patch to fix this issue https://bugs.launchpad.net/bugs/2069324/+attachment/5789277/+files/0026-Prevent-hanging-in-SIGCHLD-handler.patch |
|
| 2024-06-15 00:45:48 |
Mitchell Dzurick |
vsftpd (Ubuntu): status |
New |
Triaged |
|
| 2024-06-19 11:30:31 |
Markus Wigge |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952421 |
|
| 2024-06-20 11:21:10 |
Paride Legovini |
tags |
|
server-todo |
|
| 2024-06-20 11:21:18 |
Paride Legovini |
bug |
|
|
added subscriber Ubuntu Server |
| 2024-07-03 02:37:30 |
Bryce Harrington |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1198259 |
|
| 2024-07-03 02:37:30 |
Bryce Harrington |
bug task added |
|
vsftpd (Fedora) |
|
| 2024-07-03 02:38:47 |
Bryce Harrington |
bug task added |
|
vsftpd (Debian) |
|
| 2024-07-03 09:02:22 |
Bug Watch Updater |
vsftpd (Fedora): status |
Unknown |
Fix Released |
|
| 2024-07-03 09:02:22 |
Bug Watch Updater |
vsftpd (Fedora): importance |
Unknown |
High |
|
| 2024-07-04 23:12:29 |
Bug Watch Updater |
vsftpd (Debian): status |
Unknown |
New |
|
| 2024-07-12 07:38:21 |
Christian Ehrhardt |
vsftpd (Ubuntu): status |
Triaged |
Incomplete |
|
| 2024-07-16 07:35:46 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Jammy |
|
| 2024-07-16 07:35:46 |
Christian Ehrhardt |
bug task added |
|
vsftpd (Ubuntu Jammy) |
|
| 2024-07-16 07:35:46 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Focal |
|
| 2024-07-16 07:35:46 |
Christian Ehrhardt |
bug task added |
|
vsftpd (Ubuntu Focal) |
|
| 2024-07-16 07:35:46 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Noble |
|
| 2024-07-16 07:35:46 |
Christian Ehrhardt |
bug task added |
|
vsftpd (Ubuntu Noble) |
|
| 2024-07-16 07:35:46 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Oracular |
|
| 2024-07-16 07:35:46 |
Christian Ehrhardt |
bug task added |
|
vsftpd (Ubuntu Oracular) |
|
| 2024-07-16 07:35:53 |
Christian Ehrhardt |
vsftpd (Ubuntu Focal): status |
New |
Confirmed |
|
| 2024-07-16 07:35:56 |
Christian Ehrhardt |
vsftpd (Ubuntu Jammy): status |
New |
Confirmed |
|
| 2024-07-16 07:35:58 |
Christian Ehrhardt |
vsftpd (Ubuntu Noble): status |
New |
Incomplete |
|
| 2024-07-16 09:44:53 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/vsftpd/+git/vsftpd/+merge/469466 |
|
| 2024-07-16 09:45:08 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/vsftpd/+git/vsftpd/+merge/469467 |
|
| 2024-07-16 10:01:37 |
Christian Ehrhardt |
description |
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 |
[ 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 |
|
| 2024-07-16 10:08:45 |
Christian Ehrhardt |
description |
[ 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 |
[ 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 picked up by e.g. pam_exec.so itself.
* The fix uses waitpid over wait to be able to pass options. With that
it sets WNOHANG in vsf_sysutil_wait except if it is explicitly called
to wait as done in common_do_login for the pre-login child.
Therefore these other calls now allow it to "return immediately if
no child has exited" as defined for WNOHANG in [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 |
|
| 2024-07-16 12:50:02 |
Christian Ehrhardt |
description |
[ 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 picked up by e.g. pam_exec.so itself.
* The fix uses waitpid over wait to be able to pass options. With that
it sets WNOHANG in vsf_sysutil_wait except if it is explicitly called
to wait as done in common_do_login for the pre-login child.
Therefore these other calls now allow it to "return immediately if
no child has exited" as defined for WNOHANG in [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 |
[ Impact ]
* User impact: under certain conditions using pam_exec the vsftp server
just hangs
* Reason: 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 picked up by e.g. pam_exec.so itself.
* Fix: The fix uses waitpid over wait to be able to pass options. With that
it sets WNOHANG in vsf_sysutil_wait except if it is explicitly called
to wait as done in common_do_login for the pre-login child.
Therefore these other calls now allow it to "return immediately if
no child has exited" as defined for WNOHANG in [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 |
|
| 2024-07-19 07:04:28 |
Christian Ehrhardt |
vsftpd (Ubuntu Focal): status |
Confirmed |
In Progress |
|
| 2024-07-19 07:04:30 |
Christian Ehrhardt |
vsftpd (Ubuntu Jammy): status |
Confirmed |
In Progress |
|
| 2024-07-19 07:04:33 |
Christian Ehrhardt |
vsftpd (Ubuntu Jammy): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2024-07-19 07:04:36 |
Christian Ehrhardt |
vsftpd (Ubuntu Focal): assignee |
|
Christian Ehrhardt (paelzer) |
|
