Plugin security with dynamic class loading

Hi. I implement a plugin for language analysis. It uses an Apache UIMA annotation framework, and for reasons I have not yet figured out why, that framework loads some .jar files dynamically. That is, the plugin packages a set of .PEAR files (think of them as ZIP), each file for a specific language, and at runtime (once) the relevant file gets expanded and the framework loads (via UIMAClassLoader) the set of .jars that are in the package.

No matter what permissions I set in my plugin-security.policy, they are not applied to the dynamically loaded jars. I've debug-traced a test and I see that ESPolicy (I run w/ 5.5.1, but also tested on 5.6.4) contains this code:

// check for an additional plugin permission: plugin policy is
// only consulted for its codesources.
Policy plugin = plugins.get(location.getFile());
if (plugin != null && plugin.implies(domain, permission)) {
  return true;

I believe that's the core issue I'm getting. ESPolicy applies the permissions I set in my plugin-security.policy file to my plugin's files (those in .zip?) and its dependencies. However, since those language-dynamic .jar files do not exist on the classpath at all (as far as ES concerns, UIMAClassLoader knows where to look for them), the permissions are not applied to them.

I am not sure what should I do next? I've tried expanding one of the .PEAR files directly under src/main/resources, but still, since my pom.xml does not reference them, they are not considered plugin files.

I also thought about registering my own SecurityManager, wrapping ES's (I know it's not a good idea!), but the test fails w/ failing to create a security manager, even though I put permission java.lang.RuntimePermission "createSecurityManager"; in my plugin security file.

Has anyone created a plugin like that, which loads .jar files dynamically? Is it supported by Elasticsearch at all?

At a glance, it does not look like UIMA is setup to work with a security manager at all. It should be possible, but would require work on their end. For example, any time a PEAR loaded package needs to do something requiring SM permissions, it would need to call a method back in UIMA, which would run the call under a doPrivileged block (and the UIMA jar would have permissions for the relevant method).

I was able to work around the security issues by registering my own Policy which wraps Elastic's. The policy then grants the required permissions for the dynamically loaded .jar files.

With that, I only need to use a doPrivileged code in two places: (1) when expanding (installing) a .PEAR file and (2) once, when starting to process text.

I believe that if Elastic could somehow parse/respect permissions I set in plugin-security.policy under specific codeBase sections, even though those .jar files are not available on the classpath, I would not need to register my own Policy. But even with that work around, it seems to work fine thus far.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.