All versions > 2.0.7 of vsftp hangs directly after entering the password. Debugged this and foud vsftpd hanging in a SIGCHILD handler. This patch fixes the issue for me. I don,t know if it is correct though. Perhaps I see this problem because I amd using PAM and kerberos. --- twoprocess.c.org 2010-09-04 17:53:45.000000000 +0200 +++ twoprocess.c 2010-09-04 17:54:34.000000000 +0200 @@ -284,6 +284,8 @@ { enum EVSFPrivopLoginResult e_login_result = kVSFLoginNull; char cmd; + + vsf_sysutil_install_null_sighandler(kVSFSysUtilSigCHLD); /* Blocks */ cmd = priv_sock_get_cmd(p_sess->parent_fd); if (cmd != PRIV_SOCK_LOGIN) @@ -363,7 +365,6 @@ int was_anon = anon; const struct mystr* p_orig_user_str = p_user_str; int newpid; - vsf_sysutil_install_null_sighandler(kVSFSysUtilSigCHLD); /* Tells the pre-login child all is OK (it may exit in response) */ priv_sock_send_result(p_sess->parent_fd, PRIV_SOCK_RESULT_OK); if (!p_sess->control_use_ssl) Reproducible: Always
It doesn't hang for me. If this was a common issue I am sure somebody would have reported years ago. You need to send your patch upstream if you think this is a general problem with vsftpd
That was quick. Do you also use PAM and kerberos? The versions I have tested are 2.2.2 and 2.3.2 Could you try if my patch makes anything worse? FYI, I just sent a mail upstream too. Not sure I got the right address though.
(In reply to comment #2) > That was quick. Do you also use PAM and kerberos? > The versions I have tested are 2.2.2 and 2.3.2 > > Could you try if my patch makes anything worse? > > FYI, I just sent a mail upstream too. Not sure I got the right address > though. > I do use PAM but not kerberos Your patch seems safe but we cannot apply it. Upstream should know better ofc
(In reply to comment #3) > (In reply to comment #2) > > That was quick. Do you also use PAM and kerberos? > > The versions I have tested are 2.2.2 and 2.3.2 > > > > Could you try if my patch makes anything worse? > > > > FYI, I just sent a mail upstream too. Not sure I got the right address > > though. > > > > I do use PAM but not kerberos > > Your patch seems safe but we cannot apply it. Upstream should know better ofc > A bit odd that you "cannot apply it". Surely you can but select not to because ..? I found this email address for upstream: scarybeasts@gmail.com If you have a better way, please let upstream know about this problem. BTW, you already closed this bug, should you not leave it open until upstream has commented on the issue?
Joakim, I think we should try to get a response from upstream for your patch before considering to apply it. I asked around on #vsftpd but didn't get any answer. You said you mailed him, right? Lets wait for a while, hopefully he'll reply with more info :) I'm keeping this bug open until we sort this out.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > That was quick. Do you also use PAM and kerberos? > > > The versions I have tested are 2.2.2 and 2.3.2 > > > > > > Could you try if my patch makes anything worse? > > > > > > FYI, I just sent a mail upstream too. Not sure I got the right address > > > though. > > > > > > > I do use PAM but not kerberos > > > > Your patch seems safe but we cannot apply it. Upstream should know better ofc > > > > A bit odd that you "cannot apply it". Surely you can but select > not to because ..? > Because we cannot apply unofficial patches just because you put some effort to create them. If upstream accepts your patch I will be more than glad to commit it
(In reply to comment #5) > Joakim, I think we should try to get a response from upstream for your patch > before considering to apply it. > > I asked around on #vsftpd but didn't get any answer. > > You said you mailed him, right? Lets wait for a while, hopefully he'll reply > with more info :) Yes, but he also states on his page that he has little time for vsftpd > > I'm keeping this bug open until we sort this out. Good, meanwhile I have looked deeper into the code and it is clear to me that this is a vsftpd bug. It will only trigger if the auth procedure generates an SIGCHLD which kerberos apparently does. I doubt vsftpd works for kerberos environments. One must therefore move the vsf_sysutil_install_null_sighandler(kVSFSysUtilSigCHLD) call earlier so that any rouge SIGCHLD is eaten. vsftpd tries to do this but didn't call the above function early enough. My patch moves the call to the right place.
(In reply to comment #7) > (In reply to comment #5) > > Joakim, I think we should try to get a response from upstream for your patch > > before considering to apply it. > > > > I asked around on #vsftpd but didn't get any answer. > > > > You said you mailed him, right? Lets wait for a while, hopefully he'll reply > > with more info :) > > Yes, but he also states on his page that he has little time for vsftpd > > > > > I'm keeping this bug open until we sort this out. > > Good, meanwhile I have looked deeper into the code and it is clear > to me that this is a vsftpd bug. It will only trigger if > the auth procedure generates an SIGCHLD which kerberos apparently does. > I doubt vsftpd works for kerberos environments. > > One must therefore move the > vsf_sysutil_install_null_sighandler(kVSFSysUtilSigCHLD) call earlier > so that any rouge SIGCHLD is eaten. vsftpd tries to do this > but didn't call the above function early enough. > My patch moves the call to the right place. > No feedback at all, trying to reach upstream twice. I will stop trying now as it seems futile. I do think you should include my patch in the unstable vsftpd version so it gets some testing. Possibly it will reach upstream one day.
Fixed. Thanks a lot for your contribution. Reopen if needed
