Bug 378981

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?

Created attachment 293845 [details]
logfile: proftpd from sources  (first connection to the standard-server, second one to the virtual-host)

Created attachment 293846 [details]
logfile: proftpd from the RPM-Package  (first connection to the standard-server, second one to the virtual-host)

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.

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?

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.

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.

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.

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.

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

This change is included in the packages which should be pushed to all current branches shortly.