One problem that you encounter in a native application after you have configured a security manager is that the runtime will not initialize correctly when you load the JVM, at least it wouldn't unless you or we take special steps. In order to make the Java/C++ interaction work transparently to a native developer, the native runtime has to perform some operations that require privileges that are usually not granted by most security policies. To get things working, you can either explicitly grant the required privileges or you can use Codemesh's delegating security manager.
If you choose to go with Codemesh's delegating security manager (the default), it is installed as the system security manager in place of the one that you configured. Codemesh's security manager will grant the required privileges and delegate all other checks to your configured security manager. What are the security consequences?
On the plus side, this is much easier than trying to figure out, which privileges are required by the runtime and then having your application broken by the next version of our runtime because it requries an additional privilege.
There are of course run-modes that leave you entirely unprotected or with the above mentioned problems. If you choose to allow a pre-loaded JVM (for example because you're also using raw JNI in other places and can't be sure who gets to load the JVM), you might be running without a security manager or with an incorrectly configured one. If our runtime cannot initialize Java, you're on your own in getting things configured correctly.
xmog_jvm_loader & loader = xmog_jvm_loader::get_jvm_loader(); loader.setSecurityManager( "java.lang.SecurityManager" ); loader.setSecurityPolicy( "./app.policy" ); // the following line is redundant because this is the default loader.setUseCodemeshSecurityManager( true );
The concrete privilege grants reside in the policy file, for example:
grant
{
permission java.io.FilePermission "c:\\temp\\JC2.1\\XMOG\\staging\\examples-c++\\-", "read";
}
The above snippet will grant the application read privileges to all files in the specified directory and all its subdirectories. Incendentially, this is one of the permissions that you will have to grant your application codebase to be able to load classes from disk.
grant
{
permission java.util.PropertyPermission "java.protocol.handler.pkgs", "read,write";
permission java.util.PropertyPermission "networkaddress.cache.ttl", "read";
permission java.util.PropertyPermission "networkaddress.cache.negative.ttl", "read";
permission java.util.PropertyPermission "sun.net.inetaddr.ttl", "read";
permission java.util.PropertyPermission "user.dir", "read";
permission java.security.SecurityPermission "getProperty.networkaddress.cache.ttl";
permission java.security.SecurityPermission "getProperty.networkaddress.cache.negative.ttl";
permission java.lang.RuntimePermission "getClassLoader";
permission java.lang.RuntimePermission "setContextClassLoader";
};
1.4.1