I don't java much or else I'd submit a PR but I suspect that a trivial solution would be to File.createTempDirectory() before File.createTempFile() and apply the appropriate changes to File.createTempFile() so that the file is written into something like /tmp/scrypt instead of /tmp.
This was brought to my attention after a TPE enabled grsecurity system gave the notice:
grsec: denied untrusted exec (due to file in world-writable directory) of /tmp/scrypt199390770223188475libThe java process extracting the jar entry is included in the tpe group with the following sysctl options:
kernel.grsecurity.tpe = 1 kernel.grsecurity.tpe_invert = 1 kernel.grsecurity.tpe_restrict_all = 1
Which means the problem is almost certainly not server-side.
A closer look at https://github.com/wg/scrypt/blob/0675236370458e819ee21e4427c5f7f3f9485d33/src/main/java/com/lambdaworks/jni/JarLibraryLoader.java#L82-L112 reveals that the location of the extracted jar entry is not specified, so I assume (and I assume the underlying API assumes) that scrypt*lib will write to /tmp on UNIX-like systems.
I don't java much or else I'd submit a PR but I suspect that a trivial solution would be to File.createTempDirectory() before File.createTempFile() and apply the appropriate changes to File.createTempFile() so that the file is written into something like /tmp/scrypt instead of /tmp.
Example (suggested umasks):
umask: 0750
/tmp/scrypt/umask: 0640
/tmp/scrypt/scrypt199390770223188475libThis particularly effects https://github.com/i2p/i2p.i2p-bote
Nonetheless, thanks for the great implementation!