linking problem/question

[Marcin Krzysztof Porwit]

-----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 at centeris.com

#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-----