Dunno how to change the way JNI dlopen()'s shared objects. Try linking the PAM module .so's with -lpam or change the way PAM dlopen()'s the modules. Of course, if you're using Solaris PAM, you probably don't have source code (and if you did it probably wouldn't include recent patches), which means you're screwed -- well, almost: you can interpose/filter libdl to catch calls to dlopen() and make sure that RTLD_GLOBAL is set for opening libpam... See the linker docs at: http://docs.sun.com. Nico On Tue, Sep 04, 2001 at 06:29:19PM +0000, Andy Hutchinson wrote: > I'd like to reopen the discussion about possible dlopen anomalies when > calling PAM from Java via JNI. > > I created a C testbed to call PAM and this works fine. I had to add -lpam > and -ldl to the link line as expected but when I run nm on the testbed I > see that the calls to pam are unresolved. I think this is good since PAM is > a shared library and I don't want to statically link in the code. > > Now to the Java/JNI side of things. I basically call the same code as above > only with a JNI wrapper to it. When I run it I get error 28, module is > unknown. In the /var/log/messages file I see : > > java_ns: PAM unable to dlopen(/lib/security/pam_pwdb.so) > java_ns: PAM [dlerror: /lib/security/pam_pwdb.so: undefined symbol: > pam_get_item] > java_ns: PAM adding faulty module: /lib/security/pam_pwdb.so > > I looked into the pam source and in pam_handlers.c I can see the code which > is producing these error messages. I interpret these errors as; pam is > trying to load a module (pam_pwdb.so) which fails due to an undefined > symbol (pam_get_item). I know that pam_get_item is defined and is in the > very same library as the code which is producing the error. This leads me > to think that the code which dlopen'ed libpam.so did so without the > RTLD_GLOBAL flag set. > > Coming back to the C testbed, I certainly didn't call dlopen for libpam.so > so something else did it for me. When I run nm on the Java/JNI shared > library which I also linked with -lpam and -ldl I see again that the calls > to pam are unresolved. > > When I make the Java call to load the Java/JNI shared library this is only > to load, in effect, the same code as the C testbed - which works. When this > is in turn called it reports the fact via a printf so I know it is being > loaded. > > So to my question; I've not written any code to load libpam.so so why does > it fail when running under Java/JNI? > > There has been some discussion on the list that it's down to the Java > loadLibrary call but I don't think this is the case. If the loadLibrary > call doesn't set the RTLD_GLOBAL flag to dlopen then it just means that the > particular library cannot be used for further symbol resolution. This is > fine as there are no symbols to resolve other than the single point of entry. > > What I think is going wrong is the mechanism by which libpam.so is > magically loaded. Are there external influences such as a controlling > terminal to control how it gets loaded? > > Thanks for any help. > > Andy. > > > > _______________________________________________ > > Pam-list@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
