search

Fazecast / jSerialComm

Platform-independent serial port access for Java
GNU Lesser General Public License v3.0
1.35k stars 287 forks source link

/tmp/ is noexec on some Linux systems #387

Closed fenugrec closed 2 years ago

fenugrec commented 2 years ago

(continuing after I hijacked #277 )

I was getting errors such as

Exception in thread "Scan ports" java.lang.UnsatisfiedLinkError: Cannot load native libraries /tmp/jSerialComm/1641691463497-libjSerialComm.so or /tmp/jSerialComm/1641691463497-backup-libjSerialComm.so with expected architectures: Linux/x86_64 or Linux/x86
    at com.fazecast.jSerialComm.SerialPort.<clinit>(SerialPort.java:334)
    at dk.hkj.comm.SerialInterface.getSerialPorts(SerialInterface.java:276)
    at dk.hkj.main.InterfaceThreads$ScanPorts.run(InterfaceThreads.java:736)

For various reasons (and discussed a lot over the years, e.g. https://serverfault.com/questions/72356/how-useful-is-mounting-tmp-noexec etc) , some linux distros mount /tmp with noexec to prevent executing arbitrary files created in there.

I already knew my system was doing this (fstab has tmpfs /tmp tmpfs rw,size=4G,nr_inodes=40k,noexec,nodev,nosuid,mode=1700 ), but since the Java error didn't mention anything about permissions I didn't think about it much.

Finding a hint in unrelated issue #361, I added -Djava.io.tmpdir=/home/...tmpdir/ to start my application, and that eliminated the errors !

I have no proposed fix for this situation ( I don't java at all, just an end-user...) but would it be possible to get a more accurate diagnostic message in the case of that UnsatisfiedLinkError ? Not sure how far up the chain you can go to find the root cause... There's no global "errno", I imagine P )

Or perhaps there's an alternate method to accomplish whatever required copying those libs in the first place (also, why are they being set to Writeable ?

hedgecrw commented 2 years ago

There's unfortunately no way to further determine what caused the UnsatisfiedLinkError as this exception gets thrown by the OS itself when it tries to load the native library. For a fix that should hopefully circumvent this issue in the future, I just released v2.8.1 which will first try load the library from the system tmp directory, but if that fails, it will then try to use the user's home directory to load the library. Hopefully this cuts down on some of the confusion moving forward.

fenugrec commented 2 years ago

Perfect, thanks for looking at this.