|Summary:||bash-4.2.10-5.fc16 preventing ftp|
|Component:||bash||Assignee:||Roman Rakus <rrakus>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||awilliam, maxamillion, mike, rrakus, tsmetana|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-11-17 20:37:56 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description rbugz 2011-11-15 17:19:57 UTC
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:
Comment 1 Roman Rakus 2011-11-15 17:36:57 UTC
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
Comment 2 rbugz 2011-11-15 17:49:50 UTC
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.
Comment 3 Roman Rakus 2011-11-16 15:27:05 UTC
(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?
Comment 4 Roman Rakus 2011-11-16 15:42:39 UTC
> bash-4.2.10-4.fc16 should be the latest Typo: bash-4.2.10-5.fc16 is the latest...
Comment 5 rbugz 2011-11-16 16:42:03 UTC
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?
Comment 6 Roman Rakus 2011-11-16 17:08:02 UTC
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.
Comment 7 rbugz 2011-11-16 17:37:41 UTC
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.
Comment 8 Mike Chambers 2011-11-17 18:53:59 UTC
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.