Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm writing a pam module to let users authenticate against a PostreSQL database linked to a Django site. It works fine when I let sshd use it, but whenever I try it with vsftpd I get the following lines in /var/log/auth.log:

Jul  7 23:32:31 jeeves vsftpd: PAM unable to dlopen(pam_django.so): libsqlite3.so.0: failed to map segment from shared object: Cannot allocate memory
Jul  7 23:32:31 jeeves vsftpd: PAM adding faulty module: pam_django.so

On the client side, I get an unexpected TLS packet, and the connection fails. When I switch to pam_pwdfile.so instead, vsftpd works nicely. The only difference is the pam module.

Since the error message is about allocating memory, I ran ldd on both of the .so files, and pam_django is really dragging along quite a bit more than pam_pwdfile:

pam_django.so:
    linux-vdso.so.1 =>  (0x00007fff90b12000)
    libpq.so.5 => /usr/lib/libpq.so.5 (0x00007f35b969c000)
    libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f35b948e000)
    libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f35b90b2000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f35b8db6000)
    libconfuse.so.0 => /usr/lib/x86_64-linux-gnu/libconfuse.so.0 (0x00007f35b8baa000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f35b87ea000)
    libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f35b858c000)
    libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f35b82be000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f35b80b9000)
    libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f35b7e7b000)
    libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f35b7c2c000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f35b7a0e000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f35b780a000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f35b75f3000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f35b9ae0000)
    libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f35b73ca000)
    libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f35b71c2000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f35b6fbe000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f35b6da1000)
    liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f35b6b93000)
    libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f35b6978000)
    libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f35b6739000)
    libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f35b647d000)
    libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f35b61ff000)
    libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f35b5ff7000)
    libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f35b5d71000)
    libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f35b5ad1000)
    libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f35b589c000)
    libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f35b5687000)
    libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007f35b5476000)
    libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f35b5263000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f35b505f000)
    libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f35b4e36000)
    libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f35b4c26000)
    libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f35b49dc000)
    libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f35b4739000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f35b44ff000)


pam_pwdfile.so:
    linux-vdso.so.1 =>  (0x00007fffc41ff000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007ff57bad5000)
    libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007ff57b8c7000)
    libpam_misc.so.0 => /lib/x86_64-linux-gnu/libpam_misc.so.0 (0x00007ff57b6c2000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff57b303000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff57b0ff000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff57bf28000)

So my question then becomes: Is there a limit to how many shared libraries vsftpd can handle from its pam modules? Could it have anything to do with the way vsftpd sandboxes certain tasks? Or is the problem something else entirely?

share|improve this question

You must log in to answer this question.

Browse other questions tagged .