Bug 378981 - Pam Authentification fails with Virtual Host
Pam Authentification fails with Virtual Host
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: proftpd (Show other bugs)
8
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-12 17:31 EST by weha
Modified: 2009-01-02 10:32 EST (History)
0 users

See Also:
Fixed In Version: 1.3.1-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-02 10:32:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
logfile: proftpd from sources (first connection to the standard-server, second one to the virtual-host) (4.42 KB, text/plain)
2008-02-03 19:15 EST, weha
no flags Details
logfile: proftpd from the RPM-Package (first connection to the standard-server, second one to the virtual-host) (5.93 KB, text/plain)
2008-02-03 19:15 EST, weha
no flags Details

  None (edit)
Description weha 2007-11-12 17:31:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.8) Gecko/20071030 Fedora/2.0.0.8-2.fc8 Firefox/2.0.0.8

Description of problem:
I use the standard-proftpd.conf file (which works fine) and just added a simple VirtualHost:

<VirtualHost 192.168.0.1>
  ServerName "susi virt"
</VirtualHost>

which results in this:
I can login to the Default Server without any problem.
But when logging in to the Virtual Host, I get a login-failure, although I use the same User/Passwort (all are system-users).

Default-Server Debug-Output (proftpd -n -d4):
...
10.40.255.252 (10.40.255.252[10.40.255.252]) - dispatching CMD command 'PASS (hidden)' to mod_auth_pam.c
10.40.255.252 (10.40.255.252[10.40.255.252]) - user weha authenticated by mod_auth_pam.c

VirtualHost  Debug-Output:
...
192.168.0.1 (192.168.0.1[192.168.0.1]) - dispatching CMD command 'PASS (hidden)' to mod_auth_pam.c
192.168.0.1 (192.168.0.1[192.168.0.1]) - USER weha (Login failed): Incorrect password.

I tried this with several users on Fedora 8 and also with other Fedora machines (Fedora 2, 4, 7) - with the same result: Login to the VirtualHost fails for any  system-user.
But it perfectly works with the same configuration on RedHat9. It also works with the manually compiled sources from proftpd.org on my Fedora 8 machine. 
So it seems to me, that there must be a problem with the Fedora-RPM.

Version-Release number of selected component (if applicable):
proftpd-1.3.1-1.fc8

How reproducible:
Always


Steps to Reproduce:
1.Login as User to the Default-Server => works
2.Login as User to the VirtualHost => LoginFailure
3.

Actual Results:


Expected Results:


Additional info:
Comment 1 Matthias Saou 2008-02-03 13:18:34 EST
This is really weird. Could you please compare the PAM file from the package to
the one that gets installed from sources, and possibly find the relevant difference?
Comment 2 weha 2008-02-03 19:15:04 EST
Created attachment 293845 [details]
logfile: proftpd from sources  (first connection to the standard-server, second one to the virtual-host)
Comment 3 weha 2008-02-03 19:15:50 EST
Created attachment 293846 [details]
logfile: proftpd from the RPM-Package  (first connection to the standard-server, second one to the virtual-host)
Comment 4 weha 2008-02-03 19:16:54 EST
I use the same PAM configuration (the one, that is included in the RPM-Package),
in all my tests, also with the proftpd from sources, which means that I don't
use the PAM file that gets installed from sources. 
I realised now, that PAM-authentification is only used, when I connect to the
standard-server ["user weha authenticated by mod_auth_pam.c"], but obviously
doesn't work (or isn't used?), when I connect to the virtual-host - in both
cases. The difference is, that the from sources compiled proftpd manages
authentification by mod_auth_unix.c ["user weha authenticated by
mod_auth_unix.c", see logfile "proftpd-src-output"], whereas the RPM-proftpd 
fails with this or even doesn't switch to this method (see logfile
"proftpd-rpm-output").
So, the main question is: Why doesn't proftpd manages authentification by
mod_auth_unix.c? 
(An other qustion is: "Why isn't PAM used at all, when connexting to the virtual
host? - But this is probably not fedora-related.
Comment 5 Matthias Saou 2008-02-04 03:25:17 EST
This is strange indeed. I've checked the package build, and it does contain
mod_auth_unix. Could you try duplicating the AuthOrder and AuthPAMConfig in the
virtualhost section, just in case? Also, maybe try playing with those settings
to see if forcing mod_auth_unix first changes anything?
Comment 6 weha 2008-02-05 07:26:33 EST
Duplicating the AuthOrder and AuthPAMConfig in the virtualhost section actually
works! Starting the proftpd in debugging mode produces this output, when
connecting to the virtual host:

192.168.0.1 (::ffff:192.168.0.1[::ffff:192.168.0.1]) - AuthOrder in effect, rese
tting auth module order
...
use192.168.0.1 (::ffff:192.168.0.1[::ffff:192.168.0.1]) - user weha
authenticated by mod_auth_pam.c

So, authentification is done by mod_auth_pam.c in both cases now, mod_auth_unix
isn't used at all This is also true for the proftpd from sources now. 

I then forced the proftpd to use mod_auth_unix only. The proftpd from sources
works with this configuration. It uses mod_auth_unix for the standard server and
for the virtual host as well, whereas the proftpd form the RPM-Package doesn't
work at all now, even connecting to the standard server isn't possible:

susi (::ffff:127.0.0.1[::ffff:127.0.0.1]) - dispatching PRE_CMD command 'PASS
(hidden)' to mod_auth
susi (::ffff:127.0.0.1[::ffff:127.0.0.1]) - dispatching CMD command 'PASS
(hidden)' to mod_auth
susi (::ffff:127.0.0.1[::ffff:127.0.0.1]) - USER weha (Login failed): Incorrect
password.

All in all, duplicating the Auth entries works for me. But nevertheless, the RPM
based proftpd doesn't work as it should, I assume.
Comment 7 Matthias Saou 2008-02-05 07:59:27 EST
Indeed, the mod_auth_unix might be broken in the package from what you report. I
just tested adding mod_auth_unix explicitly to the --with-modules configure
line, but it then fails with "duplicate build request for mod_auth_unix --
aborting".

So I'm really confused. I'm also tempted to simply answer "we should always
authenticate through PAM anyway", but that doesn't actually solve the problem.

If you manage to isolate the problem, that would be great, otherwise, I don't
really know what to do.
Comment 8 weha 2008-02-05 18:04:00 EST
I finally found, what's wrong here: 
"proftpd -V" shows in the section "Features", that "Shadow file support" is
disabled in the RPM-Package. I didn't find that "--disable-shadow" was set in
your compile-time settings, so I assume, that this is a bug and not a feature(?).
To verify this, I disable shadow-support when compiling from sources, with the
expected result, that the compiled version now behaves like the one form the
package: Authentication by mod_auth_unix doesn't work.

If you decide, to enable authentication by mod_auth_unix for the future, adding
"--enable-shadow" to the "./configure" command should do this. Otherwise, I
suggest to place a hint in the proftpd.conf and/or to remove the
"mod_auth_unix.c" entry from the "AuthOrder" line.
Comment 9 Matthias Saou 2008-02-13 05:35:50 EST
I've rebuilt the latest development package with --enable-shadow passed to
configure. This should "fix" the issue, although using PAM in the virtual hosts
is probably more what you wanted in the first place ;-)
Since I've also added a module (from bug #432539), it'll worth backporting both
changes to all current branches.
Comment 10 Bug Zapper 2008-11-26 03:22:46 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Matthias Saou 2009-01-02 10:32:41 EST
This change is included in the packages which should be pushed to all current branches shortly.

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