vsftpd never really dies

Regis · 2013-12-26 21:51:11

Hello Archers,

I recently set up a FTP server on my desktop computer, with vsftpd (version 3.0.2-2 for x86_64). I start the server with "systemctl start vsftpd", and stop it with "systemctl stop vsftpd". Stopping seems to work: when I type "systemctl status vsftpd", the system answers that the daemon has been killed.

And yet, my FTP client was still able to acces the server... even after I stopped it. I eventually figured why: when a client connects to the server, the server starts some child processes. However when I stop the server (with "systemctl stop"), only the parent process is killed. The child processes remain active. The simplest way I found to really kill the server is using "systemctl kill vsftpd".

In my opinion, this can pose a security issue if the admin is not aware of this bevahior: one might think the FTP server is offline and put sensitive files on it, while it is in fact still reachable.

I believe this is a bug, but I'm not sure whether it is the responsibility of the upstream developers of vsftpd (when I kill the parent process, I would expect to kill the child processes as well), or the responsibility of the Arch packager (when I stop a daemon, I would expect that systemd kills whatever has to be killed) (assuming the systemd service file for vsftpd is written by the Arch packager).

What do you think? Is it a bug? Should I report it to the Arch Bug Tracker? Should I report it to the vsftpd developers?

Thanks for your advice.

ewaller · 2013-12-26 21:56:08

Welcome to Arch Linux. In my mind, I would post it to the Arch Bug Tracker. This is one of those cases where I would leave it to the Arch developers to kick it upstream.

WonderWoofy · 2013-12-26 21:57:04

The service file is Arch provided it seems (from just briefly looking throug ABS). So maybe the Arch bug tracker would be the place to ask about this.

In the service file it contains KillMode=process. Having this set will intentionally only kill the main process, leaving all child-processes in place. I'm not sure why this would be intentionally set this way though, as it doesn't seem to make very much sense to me. Maybe try setting KillMode=control-group? In any case, you probably want to take a look at the man pages for systemd.service and systemd.kill and compare the info there to the vfstp.service file.

Edit:
This is the service file for Arch:

[Unit]
Description=vsftpd daemon

[Service]
ExecStart=/usr/bin/vsftpd
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process

[Install]
WantedBy=multi-user.target

While this is the service file from Fedora 20's package:

[Unit]
Description=Vsftpd ftp daemon
After=network.target

[Service]
Type=forking
ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

[Install]
WantedBy=multi-user.target

So I'm not entirely sure why the Arch version over-complicates the service file in the way that it does. Also, I don't have vsftpd installed, but if the ExecStart from Fedora's specifies /etc/vsftpd/vsftpd.conf as the config, then I suspect that unless /etc/vsftpd.conf is the default config, then this should be included in Arch's ExecStart as well. But again, I don't use this package, so my knowledge of this situation is limited.

Last edited by WonderWoofy (2013-12-26 22:15:23)

Regis · 2013-12-26 23:07:19

Changing the KillMode to "control-group" did solve the problem.

I reported the bug at https://bugs.archlinux.org/task/38291.

Regarding the configuration file, the default location is /etc/vsftpd.conf on Arch, so there is nothing to worry about on that one.

Thanks for all your replies.

Arch Linux

#1 2013-12-26 21:51:11

vsftpd never really dies

#2 2013-12-26 21:56:08

Re: vsftpd never really dies

#3 2013-12-26 21:57:04

Re: vsftpd never really dies

#4 2013-12-26 23:07:19

Re: vsftpd never really dies

Board footer