#977107 proftpd-core: AuthAliasOnly and AuthUserAlias in Anonymous section cause login denied

Package:
proftpd-core
Source:
proftpd-dfsg
Description:
Versatile, virtual-hosting FTP daemon - binaries
Submitter:
Javier Kohan
Date:
2025-04-24 17:36:04 UTC
Severity:
normal
Tags:
#977107#5
Date:
2020-12-10 22:11:26 UTC
From:
To:
Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Running configuration in jessie and before. Upgraded system to stretch (didn't test in stretch) and then to buster.


Using  Useralias for websites . All was working ok, but after upgrade can not login.
proftpd[22592] xxxxxxdu.ar (localhost[::1]): USER xxxxxxxxxxxx (Login failed): No such user found
(some data edited for privacy)
UserAlias users map to www-data

Each folder of our web is configured like this:

<Anonymous /var/www/xxxxx>
        AnonRequirePassword     on
        RequireValidShell       off
        AuthAliasOnly           on
        User                    www-data
        UserAlias               xxxxx www-data
        Group                   www-data
        Umask                   003
        GroupOwner              www-data
        MaxClients              2
        AccessGrantMsg          "Acceso Permitido a %u - Toda su actividad esta siendo monitoreada."
        HideNoAccess            on
        UserPassword            www-data w4/CBsf6D7jf2
</Anonymous>

have several folders like that.


More information: we are using smbldap-tools and have users in ldap. However www-data is not in ldap, only in files (as it was from jessie and even before)



*** End of the template - remove these template lines ***

#977107#10
Date:
2020-12-11 08:02:50 UTC
From:
To:
tags 977107 + moreinfo
thanks

Please, provide the whole setup (for files that differ from distributed ones).
often evil is in details. Hide sensible information like IPs, domains and
passwords, of course.

This smells like a configuration issue which changed
from stretch times.

Thanks

#977107#17
Date:
2020-12-12 16:00:52 UTC
From:
To:
tags 977107 = confirmed upstream
severity 977107 normal

thanks

Ok, I managed to replicate the issue by using the default configuration
and your snippet on buster. It works only by removing the
AuthAliasOnly/AuthUsingAlias directives.

Also, I did a fast trial with the latest jessie version (several security
patch had been applied during its support time) with the same results.

Same results with testing and moving AuthAliasOnly in global, too.

<Anonymous /var/www/xxxxx>
       AnonRequirePassword     on
       RequireValidShell       off

	   AuthAliasOnly           on           <----- here the problem
	   AuthUsingAlias          on           <----- here the problem, even by using xxxxx for UserPassword

	   User                    www-data
       UserAlias               xxxxx www-data
       Group                   www-data
       Umask                   003
       GroupOwner              www-data
       MaxClients              2
       AccessGrantMsg          "Acceso Permitido a %u - Toda su actividad esta siendo monitoreada."
       HideNoAccess            on
       UserPassword            www-data w4/CBsf6D7jf2
</Anonymous>

#977107#28
Date:
2020-12-14 02:03:07 UTC
From:
To:
Hello. Sorry for the delay. I was on a trip this weekend.

I´m not using  "AuthUsingAlias", just "AuthAliasOnly".
I have a near default proftpd.conf and then ( in a file included from
conf.d with) 400 users defined by the snippet I already sent (without
AuthUsingAlias, as told before).

Well, removing all AuthAliasOnly from the configuration, started to work
as expected.

What I still don´t understand is if it is a bug or a configuration error.

Do you still need my proftpd.conf ?

Thanks a lot.

Javier


El 12/12/2020 a las 13:00, Francesco P. Lovergine escribió:

#977107#33
Date:
2020-12-14 08:19:35 UTC
From:
To:
Yep, I found that both directives give problems.
is confirmed by using a simple configuration.  The only strange thing
is that I found the same issue in jessie (latest from LTS security branch)
1.3.5e+r1.3.5-2+deb8u7, so the last working one was probably 1.3.5-1.1+deb8u2?

Note: Apparently a similar issue as for #4255 has been fixed in 1.3.5c and
1.3.6rc1, so it is definitively weird.