-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten, Our product accesses PAM from java, using the jpam libraries. The testing that I am doing currently shows the error on both SuSE 10.1 and on SuSE 9.2. When I enable debug logging in /etc/syslog.conf, I see the following in the log: Sep 11 06:52:57 test-basic java: PAM unable to dlopen(/lib/security/pam_unix.so) Sep 11 06:52:57 test-basic java: PAM [dlerror: /lib/security/pam_unix.so: undefined symbol: pam_get_item] Sep 11 06:52:57 test-basic java: PAM adding faulty module: /lib/security/pam_unix.so Sep 11 06:52:57 test-basic java: PAM unable to dlopen(/lib/security/pam_unix2.so) Sep 11 06:52:57 test-basic java: PAM [dlerror: /lib/security/pam_unix2.so: undefined symbol: pam_get_item] Sep 11 06:52:57 test-basic java: PAM adding faulty module: /lib/security/pam_unix2.so Sep 11 06:52:57 test-basic java: PAM unable to dlopen(/lib/security/pam_pwcheck.so) Sep 11 06:52:57 test-basic java: PAM [dlerror: /lib/security/pam_pwcheck.so: undefined symbol: pam_get_item] Sep 11 06:52:57 test-basic java: PAM adding faulty module: /lib/security/pam_pwcheck.so This code path used to work -- the only thing that has changed is the script that starts our program. It used to be a script auto-generated by install4j, and has now been replaced by a hand-rolled script. When I set LD_DEBUG=all, I see that in the old version of the code, when it comes time to resolve the symbols in pam_unix.so, the linker knows to look in /lib/libpam.so.0, whereas in the new version, no such lookup occurs. The only way to force this lookup that I have been able to find is to use the LD_PRELOAD hack. I'm trying to understand if there is anything else that controls the linking/loading sequence. I've examined the scripts that were created by install4j, and the only variable that they touch is the LD_LIBRARY_PATH, and I do the same thing in my script. Thorsten Kukuk wrote: > On Tue, Sep 12, Marcin Krzysztof Porwit wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On many of the systems that we have in-house (SuSE*, RHEL), certain >> modules explicitely list libpam.so in their ldd output, and other >> modules do not. pam_succeed_if.so has an explicit reference, but >> pam_unix.so does not, for example. > > You are missing important informations like the version you are using. > pam_unix.so is linked against libpam.so. > >> Unfortunately, this means that an >> attempt to dlopen pam_unix.so fails because symbols such as pam_get_item >> are not defined. We're able to get around this problem by specifying >> LD_PRELOAD=/lib/libpam.so when executing our code, but I'm confused as >> to how this works for any program not resorting to LD_PRELOAD. > > Because a program using the official PAM interface and not playing > around with dlopen is linked against libpam.so. > >> Any insight into what could be going on here is appreciated. > > You don't write why you dlopen the PAM module yourself and don't use > the PAM functions. This doesn't make any sense. if you use the official > PAM functions, the questions is how you was able to link your application > without linking it against libpam? > - -- Marcin Krzysztof Porwit mporwit@xxxxxxxxxxxx #include <stddisclaimer.h> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFCFKl4OZU6cX5VBERAnRLAJ9+cUS8Wm6+3jTwI529D0P7eVZHKQCfdT+L lBAy4r0Dj9rL+6DjxGn3sRw= =a76L -----END PGP SIGNATURE----- _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
