Elasticsearch version (bin/elasticsearch --version):
Version: 7.11.1, Build: default/tar/ff17057114c2199c9c1bbecc727003a907c0db7a/2021-02-15T13:44:09.394032Z, JVM: 11.0.6
Plugins installed: []
JVM version (java -version):
java version "11.0.6" 2020-01-14 LTS
OS version (uname -a if on a Unix-like system):
18.7.0 Darwin Kernel Version 18.7.0: Fri Oct 30 12:37:06 PDT 2020; root:xnu-4903.278.44.0.2~1/RELEASE_X86_64 x86_64
Description of the problem including expected versus actual behavior:
We manage our own ES cluster on k8s, and have developed a custom plug-in that needs to read a secret installed on a pod. For this we added the following to plugin-security.policy file:
permission java.io.FilePermission "/var/run/secrets/kubernetes.io/serviceaccount/token", "read";
With 7.10, this works as expected. However, the installation of the plugin fails with 7.11.1:
Exception in thread "main" java.lang.IllegalArgumentException: plugin policy [/Users/plebedev/elasticsearch-7.11.1/plugins/.installing-7543768861641787116/plugin-security.policy] contains illegal permission ("java.io.FilePermission" "/var/run/secrets/kubernetes.io/serviceaccount/token#plus" "read") in global grant
(see stack trace below).
Here is the full file:
grant {
permission java.net.SocketPermission "*", "resolve, connect";
permission java.lang.RuntimePermission "getClassLoader";
permission java.lang.RuntimePermission "setContextClassLoader";
permission java.util.PropertyPermission "guava.concurrent.generate_cancellation_cause", "read";
permission java.io.FilePermission "/var/run/secrets/kubernetes.io/serviceaccount/token", "read";
permission java.lang.RuntimePermission "setFactory";
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
permission java.lang.RuntimePermission "accessDeclaredMembers";
};
In 7.11, the following file was added:
https://github.com/elastic/elasticsearch/blob/v7.11.0/server/src/main/java/org/elasticsearch/bootstrap/PolicyUtil.java
that explicitly list permissions allowed for plug-ins, and java.io.FilePermission is not part of it.
If I simply remove this grant I will get this error:
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/var/run/secrets/kubernetes.io/serviceaccount/token" "read")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) ~[?:?]
at java.security.AccessController.checkPermission(AccessController.java:897) ~[?:?]
at java.lang.SecurityManager.checkPermission(SecurityManager.java:322) ~[?:?]
at java.lang.SecurityManager.checkRead(SecurityManager.java:661) ~[?:?]
at java.io.File.canRead(File.java:764) ~[?:?]
If this is a bug, this needs to be fixed. If this is an intended behavior, the documentation needs to be updated that this is a breaking change, and the appropriate alternative provided.
Steps to reproduce:
You can use https://github.com/elastic/elasticsearch/tree/v7.11.1/plugins/examples/painless-whitelist as a baseline, add plugin-security.policy file (as described https://www.elastic.co/guide/en/elasticsearch/plugins/current/plugin-authors.html#plugin-authors-jsm) with the permission above and try to install on 7.11.1.
Provide logs (if relevant):
Exception in thread "main" java.lang.IllegalArgumentException: plugin policy [/Users/plebedev/elasticsearch-7.11.1/plugins/.installing-7543768861641787116/plugin-security.policy] contains illegal permission ("java.io.FilePermission" "/var/run/secrets/kubernetes.io/serviceaccount/token#plus" "read") in global grant
at org.elasticsearch.bootstrap.PolicyUtil.validatePolicyPermissionsForJar(PolicyUtil.java:300)
at org.elasticsearch.bootstrap.PolicyUtil.validatePolicyPermissions(PolicyUtil.java:310)
at org.elasticsearch.bootstrap.PolicyUtil.getPluginPolicyInfo(PolicyUtil.java:321)
at org.elasticsearch.plugins.InstallPluginCommand.installPlugin(InstallPluginCommand.java:861)
at org.elasticsearch.plugins.InstallPluginCommand.execute(InstallPluginCommand.java:245)
at org.elasticsearch.plugins.InstallPluginCommand.execute(InstallPluginCommand.java:215)
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:75)
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:116)
at org.elasticsearch.cli.MultiCommand.execute(MultiCommand.java:80)
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:116)
at org.elasticsearch.cli.Command.main(Command.java:79)
at org.elasticsearch.plugins.PluginCli.main(PluginCli.java:36)
Elasticsearch version (
bin/elasticsearch --version):Version: 7.11.1, Build: default/tar/ff17057114c2199c9c1bbecc727003a907c0db7a/2021-02-15T13:44:09.394032Z, JVM: 11.0.6
Plugins installed: []
JVM version (
java -version):java version "11.0.6" 2020-01-14 LTS
OS version (
uname -aif on a Unix-like system):18.7.0 Darwin Kernel Version 18.7.0: Fri Oct 30 12:37:06 PDT 2020; root:xnu-4903.278.44.0.2~1/RELEASE_X86_64 x86_64
Description of the problem including expected versus actual behavior:
We manage our own ES cluster on k8s, and have developed a custom plug-in that needs to read a secret installed on a pod. For this we added the following to plugin-security.policy file:
With 7.10, this works as expected. However, the installation of the plugin fails with 7.11.1:
(see stack trace below).
Here is the full file:
In 7.11, the following file was added:
https://github.com/elastic/elasticsearch/blob/v7.11.0/server/src/main/java/org/elasticsearch/bootstrap/PolicyUtil.java
that explicitly list permissions allowed for plug-ins, and java.io.FilePermission is not part of it.
If I simply remove this grant I will get this error:
If this is a bug, this needs to be fixed. If this is an intended behavior, the documentation needs to be updated that this is a breaking change, and the appropriate alternative provided.
Steps to reproduce:
You can use https://github.com/elastic/elasticsearch/tree/v7.11.1/plugins/examples/painless-whitelist as a baseline, add plugin-security.policy file (as described https://www.elastic.co/guide/en/elasticsearch/plugins/current/plugin-authors.html#plugin-authors-jsm) with the permission above and try to install on 7.11.1.
Provide logs (if relevant):