LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   breaking ftp connections with vsftpd on -current (http://www.linuxquestions.org/questions/slackware-14/breaking-ftp-connections-with-vsftpd-on-current-4175425106/)

Martinus2u 09-01-2012 06:08 AM

breaking ftp connections with vsftpd on -current
 
since a recent -current upgrade I've had this issue that ftp connections in my LAN would break as soon as a data connection was opened.

I am currently on RC4.

Symptoms: midnight commander refuses to enter a directory with a red popup saying
Code:

Error - cannot change directory
In the classical ftp client the problem can be triggered by using the ls command (active or passive mode irrelevant):
Code:

ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
421 Service not available, remote server has closed connection

Code:

ftp> pa
Passive mode on.
ftp> ls
227 Entering Passive Mode (...).
150 Here comes the directory listing.
421 Service not available, remote server has closed connection

this happens for localhost and remote hosts, but not consistently for all directories.

I'm investigating, but maybe someone has an idea where else to look?

Update: normally started from inetd without tcp wrappers, i have tried standalone mode. result is the same.

Martinus2u 09-01-2012 09:41 AM

Strace reveals that the vsftpd server process is killed by a SIGSYS signal. Internet studies reveal that this signal may be related to something called "seccomp filter sandboxing" which was newly introduced in vsftpd-3.0.0.

Reverting vsftpd back to 2.3.4 (ie. the package delivered in Slackware 13.37) solves the issue.

With regards to Slackware 14, how to proceed with this?

Martinus2u 09-10-2012 04:32 PM

quick update: what I didn't know is the option
Code:

seccomp_sandbox=NO
which makes 3.0.0 work on my machine.

The other thing I found out: the issue is probably related to my kernel version (3.5.3) or config. Good news for Slackware 14.0: the issue is not present when booting the distro kernel.

Still investigating.

Martinus2u 09-16-2012 06:04 AM

update: Chris has put out version 3.0.1 which solves the issue. I had a build issue though (that can be overcome). We'll see how this pans out.

willysr 09-16-2012 09:54 AM

I built vsftpd 3.0.1 using -Current SlackBuild and it's OK here

Martinus2u 09-16-2012 12:37 PM

Strange. I found the linker choking on the command line created with the help of the script vsf_findlibs.sh. The script creates the following output on my system:

Code:

-lwrap
-lnsl
-lnsl
-lcrypt
-lcrypt
-lcrypt
-ldl
-lnsl
-lresolv
-lutil
/lib/libcap.so.2
-lssl -lcrypto

I had to replace "/lib/libcap.so.2" by "-lcap" to make it work. I'm on x86_64 and gcc-4.7.1_multilib-x86_64-1fix1_alien.

PS: just as I re-read my post it suddenly occurs to me that the missing $LIBDIRSUFFIX might be the problem.
PPS: confirmed

Martinus2u 09-18-2012 02:48 PM

for those interested, there was another seccomp issue which has now been fixed upstream by version 3.0.2.

Regarding the build issue, it only occurs in a multilib environment. The correct way of fixing it is to replace all occurrences of /lib/ by /lib$LIBDIRSUFFIX/ in vsf_findlibs.sh, and by exporting the environment variable LIBDIRSUFFIX in the Slackbuild. But as I said, it only really causes a build problem in a multilib environment, not in the Slackware binary distribution.

Marking issue as solved.


All times are GMT -5. The time now is 08:31 AM.