Login is not possible

Bug #1160372 reported by Sworddragon on 2013-03-26
298
This bug affects 77 people
Affects Status Importance Assigned to Milestone
openSUSE
Fix Released
High
vsftpd (Ubuntu)
High
Unassigned
Raring
High
Unassigned

Bug Description

* Impact:
connecting to raring vsftpd servers doesn't work

* Test Case:
- install vsftpd on raring, configure the server, try to connect to it

* Regression potential:
the server was failing to accept connections before so should only be better

---

I'm using Ubuntu 13.04 dev with vsftpd 3.0.2-1ubuntu1. local_enable and write_enable are set to YES but I'm not able to login:

sworddragon@ubuntu:~$ ftp localhost
Connected to localhost.
220 (vsFTPd 3.0.2)
Name (localhost:sworddragon): sworddragon
331 Please specify the password.
Password:
530 Login incorrect.
Login failed.

/var/log/vsftpd.log contains:

Thu Mar 21 09:00:33 2013 [pid 2] CONNECT: Client "127.0.0.1"
Thu Mar 21 09:00:48 2013 [pid 1] [sworddragon] FAIL LOGIN: Client "127.0.0.1"

/var/log/auth.log has created a line for vsftpd too:

Mar 21 12:18:29 localhost vsftpd: PAM audit_log_acct_message() failed: Operation not permitted

@tonyj: would you say the audit=0 on a commandline can work-around it?

*** Bug 811324 has been marked as a duplicate of this bug. ***

78 comments hidden view all 118 comments
Serge Hallyn (serge-hallyn) wrote :

Thanks for reporting this bug. I can't reproduce this on a new raring system. Could you please paste your entire /etc/vsftpd.conf and your /etc/pam.d/vsftpd file and any files it @includes?

Changed in vsftpd (Ubuntu):
status: New → Incomplete
importance: Undecided → High
Sworddragon (sworddragon) wrote :
Sworddragon (sworddragon) wrote :
Sworddragon (sworddragon) wrote :
Sworddragon (sworddragon) wrote :
Sworddragon (sworddragon) wrote :
Changed in vsftpd (Ubuntu):
status: Incomplete → New
74 comments hidden view all 118 comments

When attempting to start vsftpd in system services of YaST a message is returned that network-remotefs service is required. It appears vsftpd is started because port 21 is open from a remote machine but it is not possible to connect to the server.

A Linux server with no working FTP server is a real black eye!

P.S. I'm using 12.3 released version, 64 bit. This is no longer a development version issue.

(In reply to comment #30)

> A Linux server with no working FTP server is a real black eye!

Until this is fixed an easy workaround for this "black-eye" is to use pure-ftpd instead which works just fine and is functional equivalent in (almost) all practical sense to vsftpd

changed summary to match the current problem

I am facing the same problem with OpenSuSE 12.3 64bit, network install.
Pure-ftpd is reported (OpenSuSE forums) to work only if pam athentication is disabled (and local authentication enabled) in the pure-ftpd configuration.

(In reply to comment #35)
> Pure-ftpd is reported (OpenSuSE forums) to work only if pam athentication is
> disabled (and local authentication enabled) in the pure-ftpd configuration.

Strange, I'm using pure-ftpd (SuSE 12.3) with configuration

PAMAuthentication yes

and this works just fine (but vsftpd does not).

When I tried it personally, it refused to start. I will check one more time and repost.

79 comments hidden view all 118 comments
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in vsftpd (Ubuntu):
status: New → Confirmed
Lenar (lenar) wrote :

After upgrade from quantal to current raring I have the same problem too.

79 comments hidden view all 118 comments

Ubuntu bug on this also: https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/1160372

The issue is occurring because it seems vsftp has changed it's pid namespace.

Probably from sysdeputil.c::vsf_sysutil_fork_isolate_failok()
"syscall(__NR_clone, CLONE_NEWPID)"

There is a specific prohibition in the kernel on this:

-----------------------------------------------------------------------------
commit 34e36d8ecbd958bc15f8e63deade1227de337eb1
Author: Eric W. Biederman <email address hidden>
Date: Mon Sep 10 23:20:20 2012 -0700

    audit: Limit audit requests to processes in the initial pid and user namespaces.

    This allows the code to safely make the assumption that all of the
    uids gids and pids that need to be send in audit messages are in the
    initial namespaces.

    If someone cares we may lift this restriction someday but start with
    limiting access so at least the code is always correct.
-----------------------------------------------------------------------------

Regarding audit=0. I imagine it would solve the issue, rather extreme. Also if I boot with audit=0 then client side ftp fails with "500 OOPS: priv_sock_get_cmd" (seccomp_sandbox=NO in /etc/vsftpd.conf).

Can you verify if the above vsftp codepath is indeed being executed and see what happens if VSF_SYSDEP_HAVE_LINUX_CLONE is disabled.

vsftpd calls CLONE_NEWPID on SUSE - it is visible in #comment11 (see vsftpd[1]).

> Also if I boot with audit=0 then client side ftp fails with "500 OOPS:
> priv_sock_get_cmd" (seccomp_sandbox=NO in /etc/vsftpd.conf).

This does not makes any sense to me. This bug is related to enabled seccomp sanbox, but it was fixed before 12.3 release. I'll test that.

> Can you verify if the above vsftp codepath is indeed being executed and see
> what happens if VSF_SYSDEP_HAVE_LINUX_CLONE is disabled.

With a traditional fork pam session can be opened, however next test - an attempt to download the file dies on a seccomp sanbox. The same apply for a clone w/o NEW_PID, where an audit error is different. I will track this in an another bug to not pollute this one with third issue.

lowering a priority of this issue, patch is in home:mvyskocil:branches:network/vsftpd

https://build.opensuse.org/project/show?project=home%3Amvyskocil%3Abranches%3Anetwork

https://build.opensuse.org/package/view_file?expand=1&file=vsftpd-drop-newpid-from-clone.patch&package=vsftpd&project=home%3Amvyskocil%3Abranches%3Anetwork

Well, I have a question now.

Will the system be updated to run VSFTPD correctly or I have to apply the patch manually?

(In reply to comment #41)
> Well, I have a question now.
>
> Will the system be updated to run VSFTPD correctly or I have to apply the patch
> manually?

There will be a maintenance update, once all issues will be resolved.

82 comments hidden view all 118 comments
Seth Arnold (seth-arnold) wrote :

A pal spotted this bug report and suggests "[this] is caused by vsftp switching pid namespaces (audit kernel code prohibits)". Hope this helps.

83 comments hidden view all 118 comments

This is an autogenerated message for OBS integration:
This bug (786024) was mentioned in
https://build.opensuse.org/request/show/162591 Factory / vsftpd

This is an autogenerated message for OBS integration:
This bug (786024) was mentioned in
https://build.opensuse.org/request/show/162608 Maintenance /

Sent an update to 12.3 via 162608

@maintenance, please open a new maintenance incident

Hi all,

I see that the update is accepted but not yet released.
Is there an ETA on the update?
Perhaps a testing repo for the update to see if it works?

Cheers,
Angelos

Thanks Markus,

I installed the test-update repository and vsftp from there.
I get the following error:

ftp ftp://test:test@localhost
Trying ::1...
ftp: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
220 Welcome message
331 Please specify the password.
500 OOPS: vsftpd: refusing to run with writable root inside chroot()
ftp: Login failed.
ftp: Can't connect or login to host `localhost'
500 OOPS: priv_sock_get_cmd

Any ideas?

Update:

I flushed everything from my server, even the yast-ftp module.
Then I installed vsftp from test-update and it works.

Now I am having issue with Extended Passive Mode that seems to be enabled by default.

I reinstalled yast-ftp module and I get the 500 error as above.

89 comments hidden view all 118 comments
Jingwei Zhang (iceboal) wrote :

I have the same problem too. Both anonymous user and local user are unable to login.

90 comments hidden view all 118 comments

Update2:

I flushed again everything but did not manage to get it working again.
The log message when I run "service vsftpd status" shows login success, but the client reports error 500 and closes connection.

(In reply to comment #37)
> When I tried it personally, it refused to start. I will check one more time and
> repost.

Hi Ioannis,

Any updates on that? Did you manage to make it work with pure-ftp?
I am having the same problem: pure-ftp refuses to start. I upgraded from 12.2. Did you upgrade too or was it a clean install?

(In reply to comment #52)
> (In reply to comment #37)
> > When I tried it personally, it refused to start. I will check one more time and
> > repost.
>
> Hi Ioannis,
>
> Any updates on that? Did you manage to make it work with pure-ftp?
> I am having the same problem: pure-ftp refuses to start. I upgraded from 12.2.
> Did you upgrade too or was it a clean install?

Hello Angelos :)
Yes I tried again, it needs to start through xinetd or it will not start on its own (standalone). I can't say I like it, but I will live until we get the official update for vsftpd through official repos, which I am waiting for very patiantly...
Let's hope it doesn't take forever..
Guys the limitations of open source are showing in this case.. I know it's unfair, but the reaction I am gettinig in my enterprise is surprise and dissappointment. We are definately not winning over any business people like that.
Personally, I am keeping a low profile till this is resolved.

openSUSE-RU-2013:0677-1: An update that has two recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 786024,812406
CVE References:
Sources used:
openSUSE 12.3 (src): vsftpd-3.0.2-4.5.1

Unfortunately the update did not work for me.
I still get the "500 OOPS: priv_sock_get_cmd" error.
Disabling seccomp sandbox is not working for me either...

93 comments hidden view all 118 comments
MoiZie (moizie) wrote :

Same problem. Anonymous works though! Reinstalled entire system twice (quantal) and upgraded (do-release-upgrade -d) to raring. Bug occured both times.

94 comments hidden view all 118 comments

(In reply to comment #55)
> Unfortunately the update did not work for me.
> I still get the "500 OOPS: priv_sock_get_cmd" error.
> Disabling seccomp sandbox is not working for me either...

Well, without a providing any more information I cannot help you much. Would you be so kind to open a new bug?

I would need to explain

what are you try to do - do you see that with (non)-anonymous download? How your vsftpd.conf look like? Does grep 'vsftpd' /var/log/messages says anything usefull?

BTW: the output of strace -tt -s 512 of vsftpd daemon.

Created an attachment (id=535776)
configuration file that fails

Hi Michal,

Thanks for the reply. I have switched to sftp to bypass this issue.
Here is the info you asked:

# ftp ftp://ueser:*****.@localhost
Trying ::1...
ftp: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
220 Welcome message
331 Please specify the password.
500 OOPS: vsftpd: refusing to run with writable root inside chroot()
ftp: Login failed.
ftp: Can't connect or login to host `localhost'
500 OOPS: priv_sock_get_cmd

# grep 'vsftpd' /var/log/messages
Apr 18 12:38:49 aiolos xinetd[23286]: Reading included configuration file: /etc/xinetd.d/vsftpd [file=/etc/xinetd.d/vsftpd] [line=90]
Apr 18 12:39:03 aiolos xinetd[23660]: Reading included configuration file: /etc/xinetd.d/vsftpd [file=/etc/xinetd.d/vsftpd] [line=90]

Thanks,
Angelos

And the strace:

# strace -p 23677 -tt -s 512
Process 23677 attached
12:51:03.048164 accept(3, {sa_family=AF_INET, sin_port=htons(46433), sin_addr=inet_addr("109.242.165.239")}, [16]) = 4
12:51:12.678545 clone(child_stack=0, flags=CLONE_NEWIPC|SIGCHLD) = 23929
12:51:12.678783 close(4) = 0
12:51:12.678855 accept(3, 0x7fffba89a3a0, [28]) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
12:51:16.044845 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=23929, si_status=2, si_utime=0, si_stime=0} ---
12:51:16.044914 alarm(1) = 0
12:51:16.044968 rt_sigreturn() = -1 EINTR (Interrupted system call)
12:51:16.045047 alarm(0) = 1
12:51:16.045095 wait4(-1, NULL, WNOHANG, NULL) = 23929
12:51:16.045173 wait4(-1, NULL, WNOHANG, NULL) = -1 ECHILD (No child processes)
12:51:16.045224 accept(3, {sa_family=AF_INET, sin_port=htons(46434), sin_addr=inet_addr("109.242.165.239")}, [16]) = 4
12:51:16.083371 clone(child_stack=0, flags=CLONE_NEWIPC|SIGCHLD) = 23936
12:51:16.083620 close(4) = 0
12:51:16.083690 accept(3, 0x7fffba89a3a0, [28]) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
12:51:25.264770 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=23936, si_status=2, si_utime=0, si_stime=0} ---
12:51:25.264834 alarm(1) = 0
12:51:25.264882 rt_sigreturn() = -1 EINTR (Interrupted system call)
12:51:25.264936 alarm(0) = 1
12:51:25.264977 wait4(-1, NULL, WNOHANG, NULL) = 23936
12:51:25.265053 wait4(-1, NULL, WNOHANG, NULL) = -1 ECHILD (No child processes)
12:51:25.265099 accept(3, {sa_family=AF_INET, sin_port=htons(46437), sin_addr=inet_addr("109.242.165.239")}, [16]) = 4
12:51:25.302455 clone(child_stack=0, flags=CLONE_NEWIPC|SIGCHLD) = 23941
12:51:25.302684 close(4) = 0
12:51:25.302754 accept(3, ^CProcess 23677 detached
 <detached ...>

(In reply to comment #58)
> Hi Michal,
>
> Thanks for the reply. I have switched to sftp to bypass this issue.
> Here is the info you asked:
>
> # ftp ftp://ueser:*****.@localhost
> Trying ::1...
> ftp: connect to address ::1: Connection refused
> Trying 127.0.0.1...
> Connected to localhost.
> 220 Welcome message
> 331 Please specify the password.
> 500 OOPS: vsftpd: refusing to run with writable root inside chroot()
> ftp: Login failed.
> ftp: Can't connect or login to host `localhost'
> 500 OOPS: priv_sock_get_cmd

Add

    allow_writeable_chroot=YES

to the bottom of your /etc/vsftpd.conf file.

Thanks, it is working locally now.
I still cannot access from remote location (error while changing to /home/user)

Looking into it.

Thanks,
Angelos

My story:

I've done several installs of 12.3. My latest, I tried when installed to start vsftpd from YaST. It would not start, as usual, with the message that for run levels 3, 5, network-remotefs had to be installed (we all know by now there is no run lever 3 or 5 with systemd ??) I tried again a couple of days ago...same thing. I keep installing all the updates so decided last night to attemp to start vsftpd again from YaST only to discover it was running! I was able to connect from another machine! I don't know which fix did it but it seems to have healed itself in some of the updates that have been released.

Many thanks to the team working on this (and other) issues. If we get these basic things working 12.3 has potential to be the best since 11.4. KDE4.10.2 is VERY nice! Awesome!

99 comments hidden view all 118 comments
Oyvind Eriksen (i-oyvind) wrote :

Same here. Please fix!

Samir L. Boulema (sboulema-t) wrote :

I am also affected by this bug after upgrading to 13.04 :(

Jabawok (spammermattic2000) wrote :

Me too, 13.04 upgrade has caused vsftp to stop working with precisely the same symptoms:

auth.log:
Apr 26 10:36:29 ftpserv vsftpd: PAM audit_log_acct_message() failed: Operation not permitted

Tofan Sergiu (tofansergiu) wrote :

Same here :(

TommieL (tool-n) wrote :

I have serious problem because of this bug!

PAM unable to dlopen(pam_ecryptfs.so): libecryptfs.so.0: failed to map segment from shared object: Cannot allocate memory
PAM adding faulty module: pam_ecryptfs.so
pam_unix(vsftpd:auth): check pass; user unknown
pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=____ host=____
pam_winbind(vsftpd:auth): getting password (0x00000388)
pam_winbind(vsftpd:auth): pam_get_item returned a password
PAM audit_log_acct_message() failed: Operation not permitted

dyna (ubuntu-dyna) wrote :

Same here, seems to be a kernel issue. It still works with 3.5.x kernel.

Jürgen Kreileder (jk) wrote :

SuSE's fix is here https://build.opensuse.org/request/show/162591
I just rebuilt 3.0.2-1ubuntu1 with their patch, vsftpd works fine now.

Allen Crider (software-eng) wrote :

I began experiencing this problem after upgrading to Kubuntu 13.04 (from 12.10) yesterday. For now, I have removed vsftpd and installed pure-ftpd. That is working fine for my needs at the moment.

Dobz (dobz) wrote :

Exact same issue after upgrading from 12.10 to 13.04, vsftpd is now unusable.

Oyvind Eriksen (i-oyvind) wrote :

Can confirm what Jürgen Kreileder (jk) said in comment #18.
Building vsftpd 3.0.2-1ubuntu1 with the changes in vsftpd-drop-newpid-from-clone.patch from https://build.opensuse.org/request/show/162591 fixes the problem.
I basically used this guide if anyone else want to try: http://stackoverflow.com/questions/130894/how-to-build-a-debian-ubuntu-package-from-source

Oyvind Eriksen (i-oyvind) wrote :

And I tried with a fresh install so it isn't just upgrades that are affected (ref comment #1).

Zane Zakraisek (doublezane) wrote :

Same issue. Made school very difficult today when my paper was due and I could log in. hahaha. Please fix!!

description: updated
Vincent DAVY (vincentdavy) wrote :

Hi all,

I compiled the vsftpd package

Vincent DAVY (vincentdavy) wrote :

Here is the patched vsftpd version in 32bits arch.

Vincent DAVY (vincentdavy) wrote :

Hi all,

Previous messages were sent too fast and I didn't find a way to remove them.
I posted the patched version of vsftpd in both 34 and 32 bits arch : please feel free to download.

Don't forget to remove the previous installed version on your system or dpkg will tell you that the package is already installed :
sudo apt-get remove vsftpd
sudo dpkg -i vsftpd_patched.deb

That's all, and it doesn't remove config files.

If you prefer to compile your own version, here is the procedure :
mkdir vsftpd-patched
cd vsftpd-patched
sudo apt-get build-dep vsftpd
sudo apt-get install fakeroot
apt-get source vsftpd
--> Go on https://build.opensuse.org/package/view_file?file=vsftpd-drop-newpid-from-clone.patch&package=vsftpd&project=openSUSE%3AFactory&rev=3ed24d12e1827ea673331e213ab3d477 and copy/paste the patch in a file (assuming in vsftpd-drop-newpid-from-clone.patch for the rest of this tutorial)
patch -p0 < vsftpd-drop-newpid-from-clone.patch
cd vsftpd-3.0.2/
dpkg-buildpackage -us -uc -nc
cd ../

You'll get the compiled .deb in the directory.
Remove previous installed version of vsftpd on your system and install the brand new patched one.
sudo apt-get remove vsftpd
sudo dpkg -i vsftpd_patched.deb

You can remove the directory where you built the package after installation.

Vincent DAVY (vincentdavy) wrote :

Note : you need to build on a 64 bits arch to get a 64bits version of the package and a 32 bits arch for 32bits one.
I used VM for this.

Morlok8k (aoa-supercool) wrote :

I've tested Vincents 64bit patch. Confirmed fixed.

Guidouil (guidouil) wrote :

Same here on a 64bits server install. Merci Vincent

Robert Navarro (crshman) wrote :

Thanks that patch worked for me too!

Alan Tello Oyola (alan-tello) wrote :

Muchas gracias Vincent, fuciono para mi, me salvaste la vida :D
---
Thank you very much Vincent, worked for me, saved my life :D

Test 64 patch.

Jefferson (jgmdev) wrote :

Also confirming that Vincent DAVY patched vsftpd package fixes the issue.

We need a newer vsftpd on the repository as soon as possible, who knows how many people is having the same problem but haven't found this bug report, I struggled until I found this.

Phil Mundy (p-p-mundy) wrote :

I just lost hair over non responsive vsftpd on freshly updated 1304 server till I came here too.
I was having trouble with my ssh setup so I thought I'd do a quick install of ftp to transfer some keys .. LOL how wrong I was...

affects: vsftpd (openSUSE) → opensuse
Changed in opensuse:
importance: Undecided → Unknown
status: New → Unknown
GrayBear (bearcode2) wrote :

Probably everyone who had the unfortunate idea to upgrade to ubuntu 13.04 in the recent days can't use vsftpd anymore.

First I get the error "ubuntu vsftpd: PAM unable to dlopen(pam_smbpass.so)"
and then "ubuntu vsftpd: PAM audit_log_acct_message() failed: Operation not permitted"
details here: http://ubuntuforums.org/showthread.php?t=2127780&p=12641522#post12641522

Frealgagu2 (frealgagu-0) wrote :

Excuseme, how can i use the patch (#18)?
how can i compile it?
Thanks for response.

Malcolm_C (malcolm-c) wrote :

Confirm that the version in #25 is working for me too, many thanks!

Zach Collier (zachmcollier) wrote :

Confirmed that version in #26 is working in Lubuntu 13.04.

Thanks Vincent!

Changed in vsftpd (Ubuntu):
status: Confirmed → In Progress
Sebastien Bacher (seb128) wrote :

Ok, I've sponsored the proposed fix to saucy and raring and updated the bug a bit to be SRU compliant (https://wiki.ubuntu.com/StableReleaseUpdates), could somebody having the issue maybe update a bit the description to write details on the testcase and impact? (e.g what sort of configuration is impacted, how to configure a computer to reproduce the issue ... it's needed so the QA team can verify the issue and the fix once the update is available)

Changed in vsftpd (Ubuntu Raring):
importance: Undecided → High
status: New → In Progress
Changed in vsftpd (Ubuntu):
status: In Progress → Fix Committed
description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vsftpd - 3.0.2-1ubuntu2

---------------
vsftpd (3.0.2-1ubuntu2) saucy; urgency=low

  * debian/patches/13-disable-clone-newpid.patch
    - patch to remove CLONE_NEWPID syscall
      see: https://bugzilla.novell.com/show_bug.cgi?id=786024#c38
      Fixes LP: #1160372
 -- Daniel Llewellyn (Bang Communications) <email address hidden> Wed, 08 May 2013 14:08:53 +0100

Changed in vsftpd (Ubuntu):
status: Fix Committed → Fix Released
Changed in vsftpd (Ubuntu Raring):
status: In Progress → Fix Committed
tags: added: verification-needed
Morlok8k (aoa-supercool) on 2013-05-16
tags: added: verification-done
removed: verification-needed
Pascal Fares (pfares) on 2013-05-19
Changed in vsftpd (Ubuntu Raring):
status: Fix Committed → Fix Released
Robie Basak (racb) on 2013-05-20
Changed in vsftpd (Ubuntu Raring):
status: Fix Released → Fix Committed
Changed in vsftpd (Ubuntu Raring):
status: Fix Committed → Fix Released
72 comments hidden view all 118 comments

Hi, I am using Opensue 12.3 64 Bit. Freshly installed and updated to the latest packages from the update repository.

In my opinion the problems regarding the present version 3.0.2-4.5.1 of vsftp are far from resolved. As other related bugs as

https://bugzilla.novell.com/show_bug.cgi?id=806758

were marked as duplicates of this one I post my findings here.

Bug 1
******
I still need
seccomp_sandbox=NO
to connect, when TLS is enabled. With this option set to NO everything works as expected.

However, if seccomp_sandbox=YES I get the following messages in Filezilla when trying too connect from a remote system which also runs under OS 12.3:

Status: TLS/SSL-Verbindung hergestellt.
Antwort: 331 Please specify the password.
Befehl: PASS *******
Antwort: 230 Login successful.
Befehl: SYST
Antwort: 215 UNIX Type: L8
Befehl: FEAT
Antwort: 211-Features:
Antwort: AUTH TLS
Antwort: EPRT
Antwort: EPSV
Antwort: MDTM
Antwort: PASV
Antwort: PBSZ
Antwort: PROT
Antwort: REST STREAM
Antwort: SIZE
Antwort: TVFS
Antwort: UTF8
Antwort: 211 End
Befehl: OPTS UTF8 ON
Antwort: 200 Always in UTF8 mode.
Befehl: PBSZ 0
Antwort: 200 PBSZ set to 0.
Befehl: PROT P
Antwort: 200 PROT now Private.
Status: Verbunden
Status: Empfange Verzeichnisinhalt...
Befehl: CWD /
Antwort: 250 Directory successfully changed.
Befehl: PWD
Antwort: 257 "/"
Befehl: TYPE I
Antwort: 200 Switching to Binary mode.
Befehl: PASV
Fehler: GnuTLS error -15: Ein unerwartetes TLS-Paket wurde empfangen.
Fehler: Verbindung zum Server getrennt: ECONNABORTED - Connection aborted
Fehler: Verzeichnisinhalt konnte nicht empfangen werden

Bug 2 (maybe related)
******
2) Even with "seccomp_sandbox=NO", but switching to

syslog_enable=YES

I get the following message in filezilla:

Status: Connecting to 192.168.0.37:21...
Status: Connection established, waiting for welcome message...
Response: 500 OOPS: priv_sock_get_cmd
Error: Critical error
Error: Could not connect to server

Bug 3:
******
From some OS 12.3 remote systems I cannot connect in case the following option is not set to NO:

require_ssl_reuse=NO

So all in all vsftp still shows major deficiencies on Opensuse 12.3 which were not present in OS 12.2.

Any ideas what I could do ?

(In reply to comment #63)
> From some OS 12.3 remote systems I cannot connect in case the following option
> is not set to NO:
>
> require_ssl_reuse=NO
>

I have seen that the OS 12.3-systems for which the setting "require_ssl_reuse=NO"
is required all had the original Filezilla version 3.5.3 form the OS 12.3 OSS repository installed.

After installing Filezilla version 3.7.0.1 from the network repository

http://download.opensuse.org/repositories/network/openSUSE_12.3/

this problem, which is obviously client related, disappears and the setting
require_ssl_reuse=YES
works.

The other problems described in comment #63, however, remain.

guys, a fresh install of the vsftp will still show this problem, we had to use the workaround provided. If a configuration setting has changed, ie "require_ssl_reuse=NO" then we need to push this line to the default config file...!

Changed in opensuse:
importance: Unknown → High
status: Unknown → Fix Released

@abonilla, @rm: hi, please open a **new** report. It's quite hard to follow the discussion in this one. And please attach the vsftpd.conf and an output of strace -f -tt

You might copy the vsftpd.service to /etc/systemd/system/

change the ExecStart line to

ExecStart=/usr/sbin/strace -f -tt -o /run/vsftpd.strace /usr/sbin/vsftpd /etc/vsftpd.conf

and issuse systemctl daemon-reload && systemctl restart vsftpd.service

Download full text (324.3 KiB)

Dec 1 07:26:22 watcher-U56E sudo: watcher : TTY=unknown ; PWD=/home/watcher ; USER=root ; COMMAND=/usr/lib/linuxmint/mintUpdate/checkAPT.py
Dec 1 07:26:22 watcher-U56E sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 1 07:26:28 watcher-U56E sudo: pam_unix(sudo:session): session closed for user root
Dec 1 07:30:01 watcher-U56E CRON[2648]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 1 07:30:01 watcher-U56E CRON[2648]: pam_unix(cron:session): session closed for user root
Dec 1 07:41:22 watcher-U56E sudo: watcher : TTY=unknown ; PWD=/home/watcher ; USER=root ; COMMAND=/usr/lib/linuxmint/mintUpdate/checkAPT.py
Dec 1 07:41:22 watcher-U56E sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 1 07:41:29 watcher-U56E sudo: pam_unix(sudo:session): session closed for user root
Dec 1 07:56:22 watcher-U56E sudo: watcher : TTY=unknown ; PWD=/home/watcher ; USER=root ; COMMAND=/usr/lib/linuxmint/mintUpdate/checkAPT.py
Dec 1 07:56:22 watcher-U56E sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 1 07:56:30 watcher-U56E sudo: pam_unix(sudo:session): session closed for user root
Dec 1 08:11:22 watcher-U56E sudo: watcher : TTY=unknown ; PWD=/home/watcher ; USER=root ; COMMAND=/usr/lib/linuxmint/mintUpdate/checkAPT.py
Dec 1 08:11:22 watcher-U56E sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 1 08:11:28 watcher-U56E sudo: pam_unix(sudo:session): session closed for user root
Dec 1 08:17:01 watcher-U56E CRON[2784]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 1 08:17:01 watcher-U56E CRON[2784]: pam_unix(cron:session): session closed for user root
Dec 1 08:26:22 watcher-U56E sudo: watcher : TTY=unknown ; PWD=/home/watcher ; USER=root ; COMMAND=/usr/lib/linuxmint/mintUpdate/checkAPT.py
Dec 1 08:26:22 watcher-U56E sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 1 08:26:28 watcher-U56E sudo: pam_unix(sudo:session): session closed for user root
Dec 1 08:31:25 watcher-U56E mdm[1596]: pam_unix(mdm-autologin:session): session opened for user watcher by (uid=0)
Dec 1 08:31:25 watcher-U56E mdm[1596]: pam_ck_connector(mdm-autologin:session): nox11 mode, ignoring PAM_TTY :0
Dec 1 08:31:27 watcher-U56E dbus[1143]: [system] Rejected send message, 7 matched rules; type="method_return", sender=":1.18" (uid=0 pid=1779 comm="/usr/sbin/dnsmasq --no-resolv --keep-in-foreground") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.7" (uid=0 pid=1239 comm="NetworkManager ")
Dec 1 08:31:31 watcher-U56E polkitd(authority=local): Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.33 [/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Dec 1 08:31:34 watcher-U56E sudo: watcher : TTY=unknown ; PWD=/home/watcher ; USER=root ; COMMAND=/usr/lib/linuxmint/mintUpdate/checkAPT.py
Dec 1 08:31:34 watcher-U56E sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 1 08:31:42 watcher-U56E sudo: pam_unix...

Changed in vsftpd (Ubuntu):
assignee: nobody → ToshinoriTakada (to6540ta)
assignee: ToshinoriTakada (to6540ta) → nobody
Jeff Van Epps (lordbah) wrote :

I've just stumbled into this bug on 14.04.1. Worked around by commenting out "auth required pam_shells.so" in /etc/pam.d/vsftpd and restarting vsftpd as mentioned in 869684.

Displaying first 40 and last 40 comments. View all 118 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.