Bug 784286 - proftpd + pam 0:1.1.5-1.fc16 + bash 0:4.2.20-1.fc16 = impossible to login to proftpd
Summary: proftpd + pam 0:1.1.5-1.fc16 + bash 0:4.2.20-1.fc16 = impossible to login to ...
Keywords:
Status: CLOSED DUPLICATE of bug 752827
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 16
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Roman Rakus
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-24 13:31 UTC by Jérémie Grauer
Modified: 2014-01-13 00:14 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-02-29 14:28:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/secure (6.70 KB, text/plain)
2012-01-24 15:24 UTC, Jérémie Grauer
no flags Details

Description Jérémie Grauer 2012-01-24 13:31:08 UTC
Description of problem:
Version of the software (all are x86_64 arch) :

protpd version 1.3.4-1.fc16
pam version 0:1.1.5-1.fc16
bash version 0:4.2.20-1.fc16

Just install proftpd on the current Fedora 16 and you won't be able to login with any user on ftp.

The error in the log is "error 530: login incorrect", even with the correct login/pass. The exact same configuration is working fine on fully updated Fedora 15.

The solution is described here: http://forums.fedoraforum.org/showthread.php?t=273168

Basically you have to downgrade bash and pam to version 4.2.10-4.fc16 for bash and version 1.1.4-4.fc16 for pam.

This bug seems pretty critical to me since proftpd is basically broken at the moment, and possibly other software using pam and bash.

Please reclassify this bug on the correct component if you think that pam is not the right one.

Comment 1 Tomas Mraz 2012-01-24 14:45:13 UTC
Can you attach the relevant part of /var/log/secure from the failed attempt to login here? Also if you downgrade just pam or just bash, does this situation change?

Comment 2 Jérémie Grauer 2012-01-24 15:24:46 UTC
Created attachment 557254 [details]
/var/log/secure

Hello Tomas,

I tried first to downgrade only pam and the issue still occurred. I didn't try to downgrade only bash since I had to use the ftp server and I wanted it to work quickly.

Attached is the secure log file, you'll notice that I tried to log in as the user cisco without success on proftpd while it succeeded with a simple "su - cisco". Also I tried to change the cisco password and it still didn't work...

The success at the end of the log happens when I downgraded both package.

Comment 3 Tomas Mraz 2012-01-24 17:02:13 UTC
Unfortunately I cannot reproduce your problem with exactly the sam pam and bash rpms as you have. And I even see in your log that there were opened sessions for the cisco user by proftpd. So I do not think PAM is the culprit here and I would be quite surprised if bash was the culprit.

If you try to upgrade bash and pam again please also try to restart the proftpd after the upgrade.

Comment 4 Jérémie Grauer 2012-01-25 09:55:23 UTC
Too bad you couldn't reproduce it.

I'll try to upgrade bash and pam again tomorrow (I need a working proftpd today).

About the restart of proftpd, I restarted it several time. After every modification in fact (after every downgrade, etc).

I may install a brand new fedora 16 on a kvm virtual machine to try to reproduce it when I got the time.

Comment 5 j.kubiak 2012-02-28 10:14:09 UTC
Having same problem not be able to login with any user on ftp, but I have the solution:
No bug in proftpd RPM Package or PAM. But file /etc/shells doesn't contain two important lines. Add the two new lines /bin/sh and /bin/bash. Content of file /etc/shells must be:

/bin/sh
/bin/bash
/sbin/nologin
/bin/dash
/bin/zsh


Then User-FTP with witht login for proftpd is not a problem any more.
File /etc/shells comes from RPM Package setup, so this RPM Package must have the bug.

My system:
proftpd-1.3.4a-3.fc16.i686
setup-2.8.36-3.fc16.noarch

Comment 6 Ondrej Vasik 2012-02-28 17:01:06 UTC
This is broken by bash (postun of F16 GA bash package is broken, so any update is doing this nasty things) , default /etc/shells is ok ... yum reinstall bash should solve the issue.

Comment 7 Roman Rakus 2012-02-29 14:28:38 UTC

*** This bug has been marked as a duplicate of bug 752827 ***


Note You need to log in before you can comment on or make changes to this bug.