Hide Forgot
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:
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.