Description of problem: Remote ftp to any user on a Fedora 16 system using bash-4.2.10-5.fc16.x86_64 as a login shell fails with a '530' error after typing the (correct) password. The ftp server used is vsftpd. Ftp to users using a different login shell are OK. Performing a 'yum downgrade bash' (to return to bash-4.2.10-4.fc16.x86_64) fixes the problem. Version-Release number of selected component (if applicable): bash-4.2.10-5.fc16.x86_64 How reproducible: Every time. Steps to Reproduce: 1. ftp xxx (to user with bash shell on F16 machine) 2. Enter username/password 3. Actual results: ftp xxx Connected to xxx (111.222.333.444) 220 (vsFTPd 2.3.4) Name (xxx:yyy) yyy 331 Please specify the password. Password: 530 Login incorrect. Login failed. Expected results: ftp xxx Connected to xxx (111.222.333.444) 220 (vsFTPd 2.3.4) Name (xxx:yyy) yyy 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. Additional info:
Thanks for the report. Maybe it is related to bug in previous version of bash - I'm not sure if vsftpd is checking /etc/shells entries. Anyway, can you please try to update to latest bash package and reinstall it again? For more information take a look at bug #752827
Thanks for the reply. Might there be some confusion here, or is there a new version of bash I can't find? The problem I'm having is with the latest update of bash (4.2.10-5 on the Fedora server updates directory). The older version of bash (on the distro DVD) does not have the ftp problem. I had seen the /etc/shells problem bit that didn't seem to apply, in fact the /etc/shells files on all my F16 machines do contain /bin/bash (I checked before posting the above report). It was my suspicion that, in fixing the /etc/shells problem, the ftp problem has been introduced.
(In reply to comment #2) > Thanks for the reply. > > Might there be some confusion here, or is there a new version of > bash I can't find? bash-4.2.10-4.fc16 should be the latest > > The problem I'm having is with the latest update of bash (4.2.10-5 on > the Fedora server updates directory). The older version of bash (on the distro > DVD) does not have the ftp problem. > > I had seen the /etc/shells problem bit that didn't seem to apply, > in fact the /etc/shells files on all my F16 machines do contain > /bin/bash (I checked before posting the above report). > > It was my suspicion that, in fixing the /etc/shells problem, the ftp > problem has been introduced. The only change between -4 and -5 bash packages was in the scriptlet handling /etc/shells. Can you please recheck if /bin/bash is in /etc/shells? And if it's there, is your ftp working?
> bash-4.2.10-4.fc16 should be the latest Typo: bash-4.2.10-5.fc16 is the latest...
Aha! Thanks. I looked at /etc/shells on the wrong machine at the wrong time - apologies for that. With the old bash (4.2.10-4) my /etc/shells contains: /sbin/nologin /bin/dash /bin/tcsh /bin/csh /bin/zsh /bin/bash /bin/sh and ftp works (as vsftpd looks at /etc/shells). Whenever the new bash (4.2.10-5) is installed it changes my /etc/shells to: /sbin/nologin /bin/dash /bin/tcsh /bin/csh /bin/zsh ergo ftp doesn't work (for users of bash/sh) unless I add /bin/bash manually. Doing a "yum downgrade bash" reverses the process. It makes sense at last. I'm assuming the removal of shells from /etc/shells isn't intentional - or is it?
OK, I will explain what's going on here. When you upgrade from -4 to -5, the post scriptlet of -5 is run (adds /bin/bash if necessary) and then postun scriptel of -4 is run (always remove /bin/bash). The last step was buggy and was in -4 package. However when you reinstall, upgrade or remove -4 package postun is always run. In -5 package, the postun is fixed, so /bin/bash is removed only when removing bash (not removed when reinstalling or upgrading). So when you upgrade from -4 to -5 you have to reinstall -5 again and /bin/bash will be /etc/shells. I don't know about the best solution for this problem. Even if I create another newer package (-6) it doesn't make sure that /bin/bash will be there, just because people can upgrade from -4 and thus /bin/bash will not be in /etc/shells.
Thanks for the detailed explanation. I'll resolve it by updating the package and then manually adding /bin/sh and /bin/bash to /etc/shells.
Had same problem as well, and adding /bin/bash to /etc/shells did fix the problem for me too. Running the -5 bash version on server.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** This bug has been marked as a duplicate of bug 752827 ***