javaelasticsearchelasticsearch-pluginaccesscontrolexception

Reading a file in an Elasticsearch plugin


I am writing an elasticsearch plugin which relies on reading data from a file on disk. When I try to access this file in my code, I get the following exception.

Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "patient_similarity/codes.txt" "read")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at java.io.FileInputStream.<init>(FileInputStream.java:127)
at org.gatech.lucene.search.store.DotProductStore.<init>(DotProductStore.java:22)
at org.gatech.lucene.search.store.DotProductStore.newInstance(DotProductStore.java:71)
at org.gatech.elasticsearch.CommonsPlugin.onModule(CommonsPlugin.java:39)

Is there any recommended method of accessing files in elasticsearch plugins? Is there any quick workaround to access the file in my plugin?


Solution

  • One way to do this is to start the Elasticsearch process by disabling the security manager, like this:

     bin/elasticsearch -Dsecurity.manager.enabled=false
    

    Since ES 2.x, the Java security manager is enabled by default, it was disabled earlier. Note, though, that this option will be removed in 2.3 because it makes your ES process vulnerable.

    The correct way of doing this is to customize your security policy and specify the file(s) you want to access using policy files:

    grant { 
        permission java.io.FilePermission "/tmp/patient_similarity/codes.txt", "read,write";
    };
    

    You can add this policy in four different locations:

    1. either system wide in $JAVA_HOME/lib/security/java.policy
    2. or for just the elasticsearch user in /home/elasticsearch/.java.policy
    3. or from a file specified on the command line: -Djava.security.policy=someURL
    4. or in the plugin-security.policy file included in your plugin.

    Since you're developing a plugin, you should of course use option 4.