The default java.library.path on Linux does not include the library paths in the mulitarch-spec
David Holmes
david.holmes at oracle.com
Fri Jan 5 05:56:17 UTC 2024
On 5/01/2024 12:24 am, Glavo wrote:
> I expect there are security reasons why the JDK tries to find
> the file itself in these specific paths, rather than letting the
> platform code search for it.
>
>
> I think this should have nothing to do with security. If there is a
> vulnerability in the platform code, there is nothing the JDK can do to
> avoid it.
I did some archaeology and this has basically worked this way since it
was introduced way back in 1998. As far as I can see there was never any
discussion/suggestion that if we fail to find a library by the
classloader mechanisms (using java.library.path etc.) that we just pass
it through to the platform loader (e.g. dlopen) to try and find it. This
may be an oversight, or it may relate to how the classloader has to
maintain a mapping between library names and actual library files (which
would be difficult if dlopen does the searching implicitly).
> Well that is not something I would want to see implemented in hotspot.
>
>
> This is the only way I can think of to get the JDK to behave
> consistently with ld.
> Maybe we should wait and see other developers who are more familiar with
> this part.
Certainly. But IMHO neither core-libs folk, not hotspot folk, will want
to be in the business of having to load, parse and interpret
/etc/ld.so.conf and its related files.
> I'm now sending this email to panama-dev as well.
> I think this proposal is of great significance to Panama, as it will
> make it easier for developers to develop wrappers for platform libraries.
It will be interesting to see what they say.
Cheers,
David
-----
> Glavo
>
> On Thu, Jan 4, 2024 at 3:12 PM David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> On 4/01/2024 1:36 pm, Glavo wrote:
> > Hey David,
> >
> > AFAICS java.library.path (and sun.boot.library.path) are input
> > properties that can be set by the user. There are no
> "default" values
> > for these properties as such.
> >
> >
> > Although they can be set by the user, they have default values.
> > For Linux, the default value is set here:
> >
> >
> https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555> <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555>>
> >
> > The default value on Linux is the LD_LIBRARY_PATH environment
> variable
> > and the paths I mentioned earlier.
> >
> > The library loading will ultimately rely
> > on the behaviour of dlopen, if no additional paths have been
> set, so it
> > seems to me what you really want is for dlopen to act "the
> same way"
> > that ld does. Note that dlopen will already check the contents of
> > /etc/ld.so.cache
> >
> >
> > System.loadLibrary looks for the library in sun.boot.library.path
> and
> > java.library.path and passes the full path to the library to dlopen:
> >
> >
> https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254> <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254>>
> >
> > Therefore, the behavior of finding native libraries has nothing
> to do
> > with the behavior of dlopen, only sun.boot.library.path and
> > java.library.path.
>
> I stand corrected - apologies. I expected a raw name to simply get
> passed through. I thought both LD_LIBRARY_PATH and java.library.path
> could be used to expand the set of directories where the platform code
> looks for libs, not constrain things to only those paths (plus the
> defaults). I expect there are security reasons why the JDK tries to
> find
> the file itself in these specific paths, rather than letting the
> platform code search for it.
>
> > This does not seem practical. On my system ld.so.conf just
> contains
> >
> > include ld.so.conf.d/*.conf
> >
> > so now we (hotspot) have to read the top-level file, parse
> it, interpret
> > it and then recursively read, parse and interpret more files.
> >
> >
> > Yes, this is exactly the behavior I want.
>
> Well that is not something I would want to see implemented in hotspot.
>
> Cheers,
> David
> -----
>
> > Glavo
> >
> > On Tue, Jan 2, 2024 at 10:08 AM David Holmes
> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
> > <mailto:david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>>> wrote:
> >
> > Hi Glavo,
> >
> > On 24/12/2023 4:18 am, Glavo wrote:
> > > Hi,
> > >
> > > There are already many Linux distributions that are
> following the
> > > multiarch-spec[1] and adding the following paths to the
> default
> > library
> > > path list:
> > >
> > > * /usr/local/lib/<triplet>
> > > * /lib/<triplet>
> > > * /usr/lib/<triplet>
> > >
> > > But OpenJDK doesn't add these paths to the
> java.library.path by
> > default,
> > > so System.loadLibrary(String) has annoying behavior
> differences
> > with ld.
> >
> > AFAICS java.library.path (and sun.boot.library.path) are input
> > properties that can be set by the user. There are no
> "default" values
> > for these properties as such. The library loading will
> ultimately rely
> > on the behaviour of dlopen, if no additional paths have been
> set, so it
> > seems to me what you really want is for dlopen to act "the
> same way"
> > that ld does. Note that dlopen will already check the contents of
> > /etc/ld.so.cache
> >
> > > Many libraries already installed on the system cannot be
> found by
> > > System.loadLibrary(String).
> > >
> > > I wish OpenJDK would parse the /etc/ld.so.conf to get the full
> > library
> > > path list so it would be consistent with the behavior of ld.
> > > Can anyone consider this suggestion?
> >
> > This does not seem practical. On my system ld.so.conf just
> contains
> >
> > include ld.so.conf.d/*.conf
> >
> > so now we (hotspot) have to read the top-level file, parse it,
> > interpret
> > it and then recursively read, parse and interpret more files.
> >
> > Cheers,
> > David
> > ----
> >
> >
> > > Glavo
> > >
> > > [1]: https://wiki.ubuntu.com/MultiarchSpec
> <https://wiki.ubuntu.com/MultiarchSpec>
> > <https://wiki.ubuntu.com/MultiarchSpec
> <https://wiki.ubuntu.com/MultiarchSpec>>
> > > <https://wiki.ubuntu.com/MultiarchSpec
> <https://wiki.ubuntu.com/MultiarchSpec>
> > <https://wiki.ubuntu.com/MultiarchSpec
> <https://wiki.ubuntu.com/MultiarchSpec>>>
> >
>
More information about the core-libs-dev
mailing list