RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

(I am duplicating the CentOS ticket here with the bug reporters details)

Description of problem:
After a client connects to vsftpd it spawns 2 child processes. One of these processes (that owns control connection) chroots to secure_chroot_dir from vsftpd.conf (/usr/share/empty by default) and another one may chroot to /var/ftp or to user's home dir (depending on vsftpd.conf).

If we try to stop vsftpd when client is connected, then chrooted childs of vsftpd are not killed, because they are not selected by __pids_pidof() function from /etc/rc.d/init.d/functions


Version-Release number of selected component (if applicable):
vsftpd-3.0.2-22

How reproducible:
always

Steps to Reproduce:
1. Install and start vsftpd
2. Connect to it as anonymous user
3. Issue command 'service vsftpd stop'

Actual results:
Child processes are not killed. Client is still connected and can continue normal work!

Expected results:
All processes, including child processes, should be stopped.

Additional info:

Created attachment 1450642 [details]
Patch redefines __pids_pidsof() to catch chroot'd processes

Attached is a patch for the source RPM which redefines the __pids_pidof() function  from /etc/rc.d/init.d/functions locally within SOURCES/vsftpd.init to catch chroot'd procs.  This redefinition would work in any init script for processes which have chroot'd processes.

-Rich Alloway (Rogue Wave)

I don't think that doing this is wise. We shouldn't just kill all FTP sessions whenever vsftpd is stopped - in the worst case, they can be in the middle of a file transfer. Also, the vsftpd service is restarted when vsftpd is upgraded (just like any service following the guildelines). I don't think we should just kill off all FTP sessions when vsftpd is upgraded. I think that killing FTP sessions should be an explicit choice of the admin.

FWIW, this behaviour is not specific to vsftpd. For example, if you stop sshd, existing ssh sessions will continue to run.