I have a Java Application which generates a temporary JNA folder and a temporary DLL file to the following location in the users' profile:
%OSDRIVE%\Users\ABC-<SOME-USER-ID>\AppData\Local\Temp\jna--881477353\jna7513918229606912988.dll
(the JNA folder and file names contain random numbers as suffix and with prefix "jna--" , "jna" respectively)
The JNA DLL file "Path" needs to be made an exception in Application Control Policies, specifically in AppLocker -> DLL Rules -> [Users] -> Exceptions in order for the Java app to function properly. At the moment, it is blocked by the AppLocker, however, if I add this path to the AppLocker, it will work for the current user.
Now, this is achievable for 1 user, but I have many users with the prefix as "ABC-" and the suffix "SOME-USER-ID" contains a random string with numbers and letters, i.e. many users who have prefix "ABC-" should be able to use this application without the need for manually adding every users' profile path into the AppLocker configuration.
Is there a way I can "Wildcard" this path into the AppLocker configuration?
For example, something like this:
%OSDRIVE%\Users\ABC-<WILDCARD>\AppData\Local\Temp\jna--<WILDCARD>\jna<WILDCARD>.dll
or even:
%OSDRIVE%\Users\ABC-<WILDCARD>\AppData\Local\Temp\jna--<WILDCARD>\*
Is there a realistic way of achieving this via Wildcards?
I do not wish to use "*" inside the path because it will then allow ALL users to be exempted from the AppLocker settings.
Any help is appreciated.
Thanks in advance!
Based on the available documentation I could find, it appears that a wildcard (*) character is only supported in AppLocker at the beginning or end of a path, but not in the middle. So your proposed solution is impossible.
However, rather than using a wildcard in the path for AppLocker, you can pre-extract the JNA native library to a known location for all users. This is a relatively common need for security purposes (exactly your intent), sometimes related to temp directory access permissions or sometimes related to signing binaries.
From the JNA API Overview Loading JNA:
JNA includes a small, platform-specific shared library which enables all native access. When the Native class is first accessed, JNA will first attempt to load this library from the directories specified in jna.boot.library.path. If that fails and jna.nosys=false is set, it will fall back to loading from the system library paths. Finally it will attempt to extract the stub library from from the JNA jar file, and load it.
This gives you two options to avoid the randomly-named temporary file. Copy it to:
a directory of your choice, and either pass -Djna.boot.library.path=C:\your\path on the java command line, or before loading JNA call System.setProperty("jna.boot.library.path", "C:\your\path") in your program.
a system directory on the PATH, e.g. System32, and set jna.nosys=false. (You can also set jna.nounpack=true to prevent the temp file unpacking.)
In addition, the JNA native library will be in a subdirectory of the Java temporary directory specified by the java.io.tmpdir system property. See this SO question: Environment variable to control java.io.tmpdir?
Answers to that question include using the _JAVA_OPTIONS environment variable as a possible means to change the tmpdir even if you're running an executable rather than Java command line.
Related
I'm developing a simple javacard applet using the jcdk 3.0.5u3 with Eclipse Oxygen3. If I use a simple API from GlobalPlatform like the GPSystem.getCardContentState() results in error.
I've tried to add the globalplatform.jar file from GP API v1.1 and v1.6 to the Reference Libraries part of the package explorer. I also imported the "org.globalplatform.*" into the code.
import org.globalplatform.*;
if(GPSystem.getCardContentState() == GPSystem.APPLICATION_SELECTABLE){
//Do something
}
The converter returns "export file global platform.exp of package org.globalplatform not found"
Java Card doesn't just require a compile stage, it also performs the linking that is usually performed as dynamic linking in the JVM of a normal Java application. Basically it orders the methods and such, and then calls the right serial ID. You don't want your Applet to contain the string names of your fields after all: it would explode the memory requirements, and dynamically looking for classes and fields is not a good idea either within such a restricted platform.
So if you call external libraries then you need to configure:
the .jar file containing the .class files for the normal compiler;
the .exp file which contains the an export of the mapping of the normal names and the ID of the classes and fields specific for the converted classes of the called library;
If it is not already present on the card, you may also need the version specific .cap file for uploading. However, the GP functionality is should already be present on the card.
The ID's are only unique for a specific .cap file / preloaded byte code. This is why you always need the right .exp file for the code that is loaded. If another field is added, the ordering is different and the wrong fields would be linked, if the linker executes at all. So having the right .exp file is a requirement for correct conversion to .cap for your application / library.
For the JCDK I think you just need to configure the right -exportpath, as the GP should be included with the JCDK.
I have to run a java task, with a very large number of classpath (1000, totaling 150k characters if concatenated).
The problem is that java returns an error when I try to execute this class:
/jdk/JAVA8/bin/java: Argument list too long
The error code is 7
I've tried to put the classpaths using "export CLASSPATH=CLASSPATH:....." and so I shouldn't specify them through the -cp java parameter, but it returned the same error.
I'm pretty sure that the problem revolves round a classpath's limit, because if I delete some of the classpath, the error disappears (but then I will have logical errors in the execution, because I need all the classpaths)
You could use classpath wildcards. Especially if many of your jars/class files are in the same directory, this would help a lot.
It could be environment variable size limit or command-line size limit as well rather than javac classpath arg limit.
javac takes arguments from file input as well. You can add all your arguments to this file and pass this file argument to command. Refer this for more.
You didn’t hit a java-specific limitation, but a system dependent limit. This is best illustrated by the fact, that the attempt to set the CLASSPATH variable fails as well, but setting an environment variable via export name=value in the shell isn’t related to Java.
As said by others, you could try to use wildcards for jar files within the same directory, but you have to care that Java does the expansion rather than the shell, as in the latter case, it would again yield a too long command line. So you have to escape the * character to ensure it will not be processed by the shell.
javac supports reading the command line arguments from an external file specified via #filename, but unfortunately, the java launcher doesn’t support this option.
An alternative would be to create symbolic links pointing to the jar files, having shorter paths and specifying these. You could even combine the approaches by creating one directory full of symbolic links and specifying that/directory/* as class path.
But there seems to be a logical error in the requirement. In a comment, you are mentioning “code analysis” and an analyzing tool should not require having the code to analyze in its own application class path. You can access class files via ordinary I/O, if you want to read and parse them. In case you want to load them, e.g. for using the builtin Reflection, you can create new ClassLoader instances pointing to the locations. So the tool doesn’t depend on the application class path and could read the locations from a configuration file, for example.
Using distinct class loaders has the additional advantage that you can close them when you’re done.
JVM does not limit classpath length. However, there is a hard OS limit on command line length and environment variables size.
On Linux check getconf ARG_MAX to see the limit.
On older kernel versions it is only 128KB. On newer kernels it is somewhere around 2MB.
If you want to set really long classpaths, you may need a JAR-Manifest trick. See this question for details.
I need to be able to read in a property file, that lives outside of my war. My problem is that a need a solution that will allow me to tell my war file where my property file is located. Can this be done through bashrc variables and windows env variables?
I need to do this because I need to be able to drop the property file in different locations that could be away from the war file.
I am struggling to come up with a solution.
This will very much depends what the property file is for. Some libraries will have have the possibility of setting it on the command-line and others will allow you to explicitly load them in code.
In case of the latter, System.getProperties() can prove helpful, since it allows you to read properties passed to the JVM using the '-D' flag. For example
java -jar -Dfilelocation="yourfilelocation" yourapp.jar
would populate the system property 'filelocation' with the string 'yourfilelocation'. This could then be used in your code to load the property file (or whatever you want to do with it).
Since you are running inside some sort of application server, there are different ways you can accomblish this. For jetty you can put them in start.ini (or simply pass them on the command-line when you start jetty)
where tomcat uses an enviroment variable called JAVA_OPTS, so
JAVA_OPTS='-Dfilelocation=yourfilelocation' start.sh
would set the system property when you start tomcat.
one way is to provide specific location by passing java argument or setting up environment varialble and read it from app to determine the location
and as a fallback (default) app should be announcing to look at
${user.home}/appname/some.peroperties
You could defines a list of possible directories ... and try to read each one ...
I have a solution that read a property file in the file system using a default directory structure.
Eg: c:\properties\code-suit\prd\application.properties
Where:
code-suit is a variable defined by application name;
prd is a environment that I will use
Good luck
I am trying to use IM4J (a Java wrapper for ImageMagick) to create thumbnails of JPEGs and it is my first experience (ever) with both libraries. Please note that this is a hard requirement handed to me by my tech lead (so please don't suggest to use anything other than an IM4J/ImageMagick) solution - my hands are tied on the technology choice here!
I am getting a FileNotFoundException on the and convert command which tells me I don't have one of these libraries (or both) setup correctly.
On my computer, here is my directory structure:
C:/
myApp/
images/ --> where all of my JPEGs are
thumbnails/ --> where I want ImageMagick to send the converted thumbnails to
imageMagickHome/ --> Where I downloaded the DLL to
ImageMagick-6.7.6-1-Q16-windows-dll.exe
...
In my Java project, I make sure that the IM4J JAR (im4java-1.2.0.jar) is on the classpath at runtime. Although I am required to use the 1.2.0 version of IM4J, I have the liberty to use any version of ImageMagick that I want. I simply chose this version because it seemed like the most current/stable version for my Windows 7 (32-bit) machine. If I should use a different version, please send me a link to it from the ImageMagick downloads page in your answer!
As for ImageMagick, I just downloaded that EXE from here and placed it in the folder mentioned above - I didn't do any installation, wizard, MSI, environment variable configuration, etc.
Then, in my Java code:
// In my driver...
File currentFile = new File("C:/myApp/images/test.jpg"); --> exists and is sitting at this location
File thumbFile = new File("C:/myApp/thumbnails/test-thumb.jpg"); --> doesnt exist yet! (destination file)
Thumbnailer myThumbnailer = new Thumbnailer();
myThumbnailer.generateThumbnail(currentFile, thumbFile);
// Then the Thumbnailer:
public class Thumbnailer
{
// ... omitted for brevity
public void generateThumbnail(File originalFile, File thumbnailFile)
{
// Reads appConfig.xml from classpath, validates it against a schema,
// and reads the contents of an element called <imPath> into this
// method's return value. See below
String imPath = getIMPathFromAppConfigFile();
org.im4java.core.IMOperation op = new Operation();
op.colorspace(this.colorSpace);
op.addImage(originalFile.getAbsolutePath());
op.flatten();
op.addImage(thumbnailFile.getAbsolutePath());
ConvertCmd cmd = new ConvertCmd();
cmd.setSearchPath(imPath);
// This next line is what throws the FileNotFoundException
cmd.run(op);
}
}
The section of my appConfig.xml file that contains the imPath:
<imPath>C:/myApp/imageMagickHome</imPath>
Please note - if this appConfig.xml is not well-formed, our schema validator will catch it. Since we are not getting schema validation errors, we can rule this out as a culprit. However, notice my file path delimiters; they are all forward slashes. I did this because I was told that, on Windows systems, the forward slash is treated the same as a *nix backslash, in reference to file paths. Believe it or not, we are developing on Windows
machines, but deploying to linux servers, so this was my solution (again, not my call!).
IM4J even acknowledges that Windows users can have trouble sometimes and explains in this article that Windows developers might have to set an IM4JAVA_TOOLPATH env var to get this library to work. I tried this suggestion, created a new System-wide environmental variable of the same name and set its value to C:\myApp\imageMagickHome. Still no difference. But notice here I am using backslashes. This is because this env var is local to my machine, whereas the appConfig.xml is a config descriptor that gets deployed to the linux servers.
From what I can tell, the culprit is probably one (or more) of the following:
I didn't "install" the ImageMagick EXE correctly and should have used an installer/MSI; or I need to add some other environmental variables for ImageMagick (not IM4J) itself
Perhaps I still don't have IM4J configured correctly and need to add more environmental variables
Could be the Windows/*nix "/" vs. "" issue from my appConfig.xml file as mentioned above
I'm also perplexed as to why I'm getting a FileNotFoundException on a file named "convert":
java.io.FileNotFoundException: convert
I assume this is a batch/shell file living somewhere inside the IM4J jar (since the only thing I downloaded for ImageMagick was the EXE). However, if I extract the IM4J jar I only see classes inside of it. I see "script generator" classes, so I assume these kick off before my cmd.run(op) call and create the convert file, and maybe that's what I'm missing (perhaps I need to manually kick off one of these generators, like CmdScriptGenerator prior to executing my Thumbnailer methods. . Or, maybe my download is incomplete.
Either way, I'm just not versed enough with either library to know where to start.
Thanks for any help with this.
Run the 'ImageMagick-6.7.6-1-Q16-windows-dll.exe' installer first to install the imagemagick libraries. Then make sure your environment path includes the location of the installed binaries ('convert.exe', 'mogrify.exe', etc)
Make sure u have Set the environment-variable IM4JAVA_TOOLPATH.
I'm using launch4j to wrap an executable jar file in my Windows application, but I need to pass references to some of its libraries in through the JVM arguments. The libraries in question reside in the application install directory, and are always located in the same place, relative to the executable.
I'd like to tell launch4j to use executable-relative paths in the JVM options. I know this information is available at the Windows batch script level, but how do you configure launch4j to fetch it?
Edit for clarification: I'm looking specifically for how to make the paths relative to the binary itself, not how to make them relative to the current working directory. The two aren't necessarily the same.
You might add to your launch4j configuration
...
<jre>
...
<opt>-Djna.library.path="%EXEDIR%\\path\\to\\lib"</opt>
<opt>-Djava.library.path="%EXEDIR%\\path\\to\\lib"</opt>
...
</jre>
...
If you need more then a you might seperate several paths by a semikolon as usual.
< opt> Optional, accepts everything you would normally pass to
java/javaw launcher: assertion options, system properties and X
options. Here you can map environment and special variables EXEDIR
(exe's runtime directory), EXEFILE (exe's runtime full file path) to
system properties. All variable references must be surrounded with
percentage signs and quoted.
Source: http://launch4j.sourceforge.net/docs.html
Set -Djna.library.path=<relative path of native libraries> (if using JNA) and -Djava.library.path=<relative path of native libraries>.
Alternatively, this can be done in Java code as: System.setProperty("jna.library.path","<relative path of native libraries>") and System.setProperty("java.library.path","<relative path of native libraries>"). You can append as many paths to refer to. In Windows, use ; to separate the paths.
This setup only has its effect on the JVM runtime of that Java application (not globally like LD_LIBRARY_PATH in Linux.)
Or, you can put this in Launch4J JVM options list under JRE tab. This is what I do in my projects.
One of the options in configuration is to allow a change directory chdir to the executables directory. This will set user.dir to same directory as exe, which you could use to find other application paths.
<chdir>
Optional. Change current directory to an arbitrary path relative to the executable. If you omit this property or leave it blank it will have no effect.
Setting it to . will change the current dir to the same directory as the executable. .. will change it to the parent directory, and so on.
<chdir>.</chdir>
<chdir>../somedir</chdir>
The code which find the actual path to executable will be dependent on OS (readlink, GetModuleFileName etc). Make sure you really test on target OSes..
If I understand your question correct, you have a launch4j executable and a native library within your installation directory:
/launch.exe
/bin/lib.dll
/lib/app.jar
Now you want to start you app.jar with the generated launcher (launch.exe). You app loads the lib.dll.
You can embed a file into your app.jar (marker.txt). Now you can use the ClassLoader
http://docs.oracle.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)
getResource("marker.txt);
This will give you something like:
file://c://installdir/lib/app.jar!marker.txt
This String can be parsed. But in fact, I think there should be a better solution for this problem.
You can simply include the directory (e.g. ..\lib) where the libraries are located in the classpath tab in Launch4j. At least that worked for me.