You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When /tmp is mounted as noexec on Linux, sqlite-jdbc fails to load the native library with an error similar to the following:
java.lang.UnsatisfiedLinkError: /tmp/sqlite-...-libsqlitejdbc.so: /tmp/sqlite-...-libsqlitejdbc.so: failed to map segment from shared object
Users can fix this by not mounting /temp as noexec, or by specifying a custom java.io.tmpdir or org.sqlite.tmpdir system property value pointing to an (existing) directory with execution permission.
But just based on the UnsatisfiedLinkError above, it might not obvious to users what the cause is, or how to fix it.
Describe the solution you'd like
sqlite-jdbc should try to detect noexec or other permission errors and report them properly before trying to load the native library and causing an UnsatisfiedLinkError,
or better (?) trigger an UnsatisfiedLinkError but attach additional information, such as whether permissions are correct.
Additionally it could suggest to set the java.io.tmpdir or org.sqlite.tmpdir system property value to an (existing) directory with execution permission.
Additional context
Maybe the checks in SQLiteJDBCLoader.extractAndLoadLibraryFile should be improved:
It does not check the return value of the setReadable, ... calls
After the setExecutable call it should call file.canExecute()
It seems for noexecfile.setExecutable(true) succeeds but file.canExecute() is still false afterwards, so it could be detected like this.
However, I am not that familiar with Linux and the implementation details of java.io.File, so maybe there are cases where for example setReadable, ... fails but the library can still be loaded.
So maybe these checks should only be performed if an UnsatisfiedLinkError occurs, to provide additional troubleshooting information.
Potentially useful: netty/netty#6707, but I am not sure if using PosixFilePermission is really needed or if using the java.io.File API suffices.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When
/tmp
is mounted asnoexec
on Linux, sqlite-jdbc fails to load the native library with an error similar to the following:Users can fix this by not mounting
/temp
asnoexec
, or by specifying a customjava.io.tmpdir
ororg.sqlite.tmpdir
system property value pointing to an (existing) directory with execution permission.But just based on the
UnsatisfiedLinkError
above, it might not obvious to users what the cause is, or how to fix it.See related issues:
Describe the solution you'd like
sqlite-jdbc should try to detect
noexec
or other permission errors and report them properly before trying to load the native library and causing anUnsatisfiedLinkError
,or better (?) trigger an
UnsatisfiedLinkError
but attach additional information, such as whether permissions are correct.Additionally it could suggest to set the
java.io.tmpdir
ororg.sqlite.tmpdir
system property value to an (existing) directory with execution permission.Additional context
Maybe the checks in
SQLiteJDBCLoader.extractAndLoadLibraryFile
should be improved:sqlite-jdbc/src/main/java/org/sqlite/SQLiteJDBCLoader.java
Lines 207 to 209 in 2e336d9
Issues with the current implementation:
setReadable
, ... callssetExecutable
call it should callfile.canExecute()
It seems for
noexec
file.setExecutable(true)
succeeds butfile.canExecute()
is stillfalse
afterwards, so it could be detected like this.However, I am not that familiar with Linux and the implementation details of
java.io.File
, so maybe there are cases where for examplesetReadable
, ... fails but the library can still be loaded.So maybe these checks should only be performed if an
UnsatisfiedLinkError
occurs, to provide additional troubleshooting information.Potentially useful: netty/netty#6707, but I am not sure if using
PosixFilePermission
is really needed or if using thejava.io.File
API suffices.The text was updated successfully, but these errors were encountered: