[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Pam called from Java/JNI - again

Brilliant, the LD_PRELOAD does the trick. Many thanks.


At 16:53 04/09/01 -0500, you wrote:
Andy Hutchinson <andy@extensible.co.uk> writes:

> So to my question; I've not written any code to load libpam.so so why
> does it fail when running under Java/JNI?

When you are running your C testbed, the main application has been linked
with -lpam.  So libpam.so is included in the list of libraries for
resolving externals in subsequent calls to dlopen().

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

Yes, but it is not _just_ that library that won't be used for further
symbol resolution.  None of the libraries that IT relies on will be
consulted either.  So libpam is loaded in memory, but not in the search

You could get around this by forcing java to use RTLD_GLOBAL, or perhaps
setting LD_PRELOAD before launching your java app.  Something like:

LD_PRELOAD=/usr/lib/libpam.so java foo.jar

Ceterum censeo vi esse delendam

Pam-list mailing list

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []