Description of problem: Ftp access for local users is not possible even when enabled via vsftpd.conf. Error returned by client: Login failed: 530 Login incorrect. Error in vsftpd.log (if standard xferlog is disabled): Thu Aug 8 06:27:21 2013 [pid 2] CONNECT: Client "::ffff:127.0.0.1" Thu Aug 8 06:27:26 2013 [pid 1] [local_username] FAIL LOGIN: Client "::ffff:127.0.0.1 Error in auth.log (if enabled by installing rsyslog): Aug 8 08:32:49 gmerigo-wks3 vsftpd[4817]: pam_tcb(vsftpd:auth): Authentication passed for gmerigo from (uid=0) Aug 8 08:32:49 gmerigo-wks3 vsftpd[4817]: PAM audit_log_acct_message() failed: Operation not permitted (END) Version-Release number of selected component (if applicable): Version : 3.0.2 Release : 2.mga3 How reproducible: Install a brand new vsftpd rpm, and add/uncomment these options: local_enable=YES xferlog_file=/var/log/vsftpd.log xferlog_std_format=NO Steps to Reproduce: 1. Install vsftpd 2. Apply options as above 3. Start vsftpd (systemctl start vsftpd.service) 4. Try to login with a valid local user (not root) Reproducible: Steps to Reproduce:
I see that other distros have issued patches: https://build.opensuse.org/request/show/162591 So maybe it's only a matter of finding if they work, apply them and rebuild the packages...
Assignee: bugsquad => pterjan
I have never used vsftpd, better fine someone else :(
Assignee: pterjan => bugsquad
Giuseppe, thanks for the report! Thanks also for finding the patch. I have uploaded patched packages for Mageia 3 and Cauldron with the patch. The Mageia 3 package is currently in core/updates_testing. Please test it and let me know if it works for you. Advisory: ---------------------------------------- This update fixes a user login problem in vsftpd. ---------------------------------------- Updated packages in core/updates_testing: ---------------------------------------- vsftpd-3.0.2-2.1.mga3 from vsftpd-3.0.2-2.1.mga3.src.rpm
CC: (none) => luigiwalserAssignee: bugsquad => qa-bugs
Hi David, I installed the update in two machines in which I had the problem, and it's gone! I think you can close the bug. I don't know if you need additional testing to promote the package to core/updates and have vsftpd working availlable for anyone.
Testing complete mga3 64 Before ------ Installed and set up /etc/vsftpd/vsftpd.conf as described in comment 0 Started in standalone mode with 'service vsftpd start' $ ftp localhost Connected to localhost. 220 (vsFTPd 3.0.2) 530 Please login with USER and PASS. Name (localhost:claire): claire 331 Please specify the password. Password: 530 Login incorrect. Login failed. ftp> bye 221 Goodbye. After ----- $ ftp localhost Connected to localhost. 220 (vsFTPd 3.0.2) 530 Please login with USER and PASS. Name (localhost:claire): claire 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> bye 221 Goodbye. Also verified that an incorrect login/password still prevented login. I'd like to say it was on purpose.
Whiteboard: (none) => has_procedure mga3-64-ok
It's tested by the QA team first Giuseppe on both architectures. (You're welcome to join us! https://wiki.mageia.org/en/Contributing) Did you test this i586 when you checked it?
There is an error when uninstalling David, might be worth fixing at the same time. warning: file /etc/rc.d/init.d/vsftpd: remove failed: No such file or directory
Whiteboard: has_procedure mga3-64-ok => has_procedure mga3-64-ok feedback
@Claire yes, one of my machines is i586 and the other is x86_64. Of course I didn't try to uninstall... I think the problem here is the mageia use systemd and one of the patches try to update the old sysvinit file.
Yes, it looks that way Giuseppe. It looks like it should be an easy fix so may be worth doing at the same time. Thanks for testing, adding that it's ok i586 too, but it will need testing again if it's rebuilt.
Whiteboard: has_procedure mga3-64-ok feedback => has_procedure mga3-64-ok mga3-32-ok feedback
I'm assuming it doesn't actually leave any files behind, so the error message isn't causing any problems. I have no idea why it's doing that...I don't see anything obviously wrong in the SPEC file. We could remove the init script from the package, since it has a native systemd service file. I don't see any reason to do that for an update though.
Whiteboard: has_procedure mga3-64-ok mga3-32-ok feedback => has_procedure mga3-64-ok mga3-32-ok
It's strange as the file is included in the package, along with the systemd service. # urpmf vsftpd | grep -e init -e service vsftpd:/etc/avahi/services/vsftpd.service vsftpd:/etc/rc.d/init.d/vsftpd vsftpd:/lib/systemd/system/vsftpd.service I created bug 11047 for it anyway.
Validating. Advisory uploaded. Could sysadmin please push from 3 core/updates_testing to updates Thanks!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
@claire could the init.d file be included in one of the patches introduced for this bug? Maybe there's some inclusion that put the file in the rpm if there isn't one alreaedy? I'm not very familiar with spec files even if I meddled with them sometimes, but it seems that there's something like this in the spec patch: %preun +if [ -e /etc/init.d/%{name} ]; then %stop_on_removal %name +fi Maybe the spec file for mageia did not include this check?
Update pushed: http://advisories.mageia.org/MGAA-2013-0089.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED