Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/tmp mounted with noexec is not handled gracefully #987

Closed
Equidamoid opened this issue Jun 10, 2024 · 1 comment
Closed

/tmp mounted with noexec is not handled gracefully #987

Equidamoid opened this issue Jun 10, 2024 · 1 comment

Comments

@Equidamoid
Copy link

Equidamoid commented Jun 10, 2024

Version

3.3.3

Platform

Linux x64

JDK

11.0.14

Module

lwjgl core

Bug description

org.lwjgl.system.Library & co contain an assumption that if it can write an .so file to a certain path, then it can system.LoadLibrary() it, which is sometimes incorrect and causes unhandled exceptions.

A frequent example is having /tmp mounted with noexec flag. The user tries to run the application, lwjgl extracts its native library to /tmp/lwjgl_$USERNAME/..., and the following System.loadLibrary() throws because its underlying dlopen call is denied by the system.

It is possible to to use -Djava.io.tmpdir as a workaround, but it is near impossible for an average (non-programmer) user to figure out. Even adding this flag may be a challenge, as some applications (e.g. games) don't provide an easy way to add jvm flags. Moreover, sometimes the path is just ignored (I guess due to some application-dependent configuration).

Denying write access to /tmp/lwjgl_$USERNAME also helps (and causes the .so to be written to $HOME/.lwjgl/...), but again, not obvious and user-friendly.

Some examples of the problem occurring in various games:

I'm not sure what is the best way of fixing this problem. Some options are:

  • try another path when system.LoadLibrary() fails (in the same way as if extracting the library failed)
  • add more info to the exception
  • advise the application developers to place .so to a known "good" location (e.g. withing the game files) and not to rely on the auto-unpacking mechanism

Stacktrace or crash log output

java.lang.UnsatisfiedLinkError: /tmp/lwjgl_xxxxx/3.3.3-snapshot/x64/liblwjgl.so: /tmp/lwjgl_xxxxx/3.3.3-snapshot/x64/liblwjgl.so: failed to map segment from shared object
        at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
        at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
        at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
        at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
        at java.base/java.lang.Runtime.load0(Runtime.java:768)
        at java.base/java.lang.System.load(System.java:1837)
        at org.lwjgl.system.Library.loadSystem(Library.java:189)
        at org.lwjgl.system.Library.loadSystemFromLibraryPath(Library.java:179)
        at org.lwjgl.system.Library.loadSystem(Library.java:132)
        at org.lwjgl.system.Library.loadSystem(Library.java:64)
        at org.lwjgl.system.Library.<clinit>(Library.java:52)
@Spasi
Copy link
Member

Spasi commented Jun 11, 2024

Thank you @Equidamoid!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants