I've got libcap and am using it in my /etc/pam.d/system-auth, as such: auth required pam_cap.so sudo breaks with the following error message: $ sudo -i Password: sudo: pam_authenticate: Module is unknown This is left in the logs: sudo: PAM unable to dlopen(/lib64/security/pam_cap.so): /lib64/security/pam_cap.so: undefined symbol: pam_get_item sudo: PAM adding faulty module: /lib64/security/pam_cap.so sudo: _myusername_ : pam_authenticate: Module is unknown ; TTY=pts/4 ; PWD=/home/_myusername_ ; USER=root ; COMMAND=/bin/bash Using sys-libs/pam-1.1.5 and app-admin/sudo-1.8.1_p2. Use flags follow: sys-libs/libcap-2.22 was built with the following: USE="(multilib) pam" sys-libs/pam-1.1.5 was built with the following: USE="berkdb cracklib (multilib) nls vim-syntax -audit -debug -nis (-selinux) -test" app-admin/sudo-1.8.1_p2 was built with the following: USE="(multilib) pam -ldap -offensive (-selinux) -skey" This seems to be the following bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591410
Forgot to mention: the breakage happened after an upgrade yesterday, from libcap-2.17.
Undefined symbols in pam_cap.so: $ nm -u -D /lib64/security/pam_cap.so w _Jv_RegisterClasses w __cxa_finalize w __gmon_start__ U __sprintf_chk U __strdup U __vsyslog_chk U cap_free U cap_from_text U cap_get_proc U cap_set_proc U cap_to_text U closelog U fclose U fgets U fopen64 U free U malloc U openlog U pam_get_item U pam_get_user U strcmp U strcpy U strlen U strtok pam_get_item and pam_get_user are defined in libpam.so: $ nm -D /lib64/libpam.so | grep -E 'pam_get_(item|user)' 0000003608e06840 T pam_get_item 0000003608e069c0 T pam_get_user However, pam_cap.so does not link against it: $ ldd /lib64/security/pam_cap.so linux-vdso.so.1 => (0x00007fff3e789000) libcap.so.2 => /lib64/libcap.so.2 (0x00007fb8c6082000) libc.so.6 => /lib64/libc.so.6 (0x00007fb8c5d17000) libattr.so.1 => /lib64/libattr.so.1 (0x00007fb8c5b11000) /lib64/ld-linux-x86-64.so.2 (0x0000003167600000)
you need to post `emerge --info` in every report ... upstream specifically does not link against -lpam ... thinking about it, it should just work anyways since sudo is linked against libpam, and it's libpam that is loading this module, so the module should be able to locate symbols from that search path.
Created attachment 291779 [details] emerge --info Seeing the same behavior. It looks like pam_cap.so is not being linked to libpam despide the use flag being enabled: pangur adborden # equery u libcap [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-libs/libcap-2.22: U I + + pam : Adds support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip sys-libs/libcap-2.22: pangur adborden # ldd /lib64/security/pam_cap.so linux-vdso.so.1 => (0x00007fff68bbb000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f18bbc28000) libc.so.6 => /lib64/libc.so.6 (0x00007f18bb8c2000) libattr.so.1 => /lib64/libattr.so.1 (0x00007f18bb6bc000) /lib64/ld-linux-x86-64.so.2 (0x00007f18bc05a000) sys-libs/libcap-2.17: pangur adborden # ldd /lib64/security/pam_cap.so linux-vdso.so.1 => (0x00007fff3d5ff000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f0fc07d2000) libpam.so.0 => /lib64/libpam.so.0 (0x00007f0fc05c5000) libc.so.6 => /lib64/libc.so.6 (0x00007f0fc025e000) libattr.so.1 => /lib64/libattr.so.1 (0x00007f0fc0059000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f0fbfe55000) /lib64/ld-linux-x86-64.so.2 (0x00007f0fc0c04000)
Why does nobody fix this bug? Not being able to use sudo is annoying. [adrian@cheops3:~]> sudo su - Password: sudo: pam_authenticate: Module is unknown [adrian@cheops3:~]>
Mike, if pam_cap does not lik to libpam it might get the wrong symbol versions, so please make it link libpam.
i don't understand what you mean. pam loads the module, so its symbols are available already. if pam_cap.so was built against a newer pam than the libpam.so that is resident in memory, there could possibly be a mismatch, but there would already be a problem as you'd have the host process (let's say "sshd") using one version of libpam and the modules it loads using a different version. the only sane thing there would be to rebuild/reload everything.
also from upstream source Makefile: # Note (as the author of much of the Linux-PAM library, I am confident # that this next line does *not* require -lpam on it.) If you think it # does, *verify that it does*, and if you observe that it fails as # written (and you know why it fails), email me and explain why. Thanks!
