ProFTPD mod_auth_pam broken while using new glibc (starting from 4.33)

[vincdrouin]

What I Did

• Using proftpd 1.3.8 compiled with buildroot, using glibc >=4.33
• Using default CONF OPTS suggested by buildroot (https://github.com/buildroot/buildroot/blob/master/package/proftpd/proftpd.mk)
  -> building with mod_sftp
  -> added a dependancy on linux-pam
  -> enabling TLS / openssl

1. Tried authentication with local user
2. Tried authentication using LDAP/AD through nslcd and PAM

What I Expected/Wanted

What I expected : a behaviour identical to proftpd using glibc <= 4.32

1. successful SFTP authentication with local user
2. successful SFTP authentication using AD user

With glibc 4.32, when proftpd fails to find local user, it lets PAM/nslcd try connection.
With glibc 4.33, when proftpd fails to find local user, the authentication is aborted without askin PAM/nslcd.

If I build mod_radius and configure proftpd to ask a fake RADIUS server, after trying and failing RADIUS, proftpd asks PAM/nslcd to do the authentication.

So there is clearly an issue with how proftpd behaves using new glibc releases.

[Castaglia]

I'm not aware of anything in how ProFTPD uses the PAM API that would result in the behavior you're seeing.

How might I reproduce this locally? That is, how/where might I find a Docker image that contains/uses this glibc 4.33 version, for testing?