honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/plugins/authors.asciidoc

121 lines
4.8 KiB
Plaintext
Raw Normal View History

Docs: Prepare plugin and integration docs for 2.0 * Centralised plugin docs in docs/plugins/ * Moved integrations into same docs * Moved community clients into the clients section of the docs * Removed docs/community Closes #11734 Closes #11724 Closes #11636 Closes #11635 Closes #11632 Closes #11630 Closes #12046 Closes #12438 Closes #12579
2015-08-15 12:00:55 -04:00
[[plugin-authors]]
== Help for plugin authors
Add the ability to bundle multiple plugins into a meta plugin (#28022) This commit adds the ability to package multiple plugins in a single zip. The zip file for a meta plugin must contains the following structure: |____elasticsearch/ | |____ <plugin1> <-- The plugin files for plugin1 (the content of the elastisearch directory) | |____ <plugin2> <-- The plugin files for plugin2 | |____ meta-plugin-descriptor.properties <-- example contents below The meta plugin properties descriptor is mandatory and must contain the following properties: description: simple summary of the meta plugin. name: the meta plugin name The installation process installs each plugin in a sub-folder inside the meta plugin directory. The example above would create the following structure in the plugins directory: |_____ plugins | |____ <name_of_the_meta_plugin> | | |____ meta-plugin-descriptor.properties | | |____ <plugin1> | | |____ <plugin2> If the sub plugins contain a config or a bin directory, they are copied in a sub folder inside the meta plugin config/bin directory. |_____ config | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> |_____ bin | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> The sub-plugins are loaded at startup like normal plugins with the same restrictions; they have a separate class loader and a sub-plugin cannot have the same name than another plugin (or a sub-plugin inside another meta plugin). It is also not possible to remove a sub-plugin inside a meta plugin, only full removal of the meta plugin is allowed. Closes #27316
2018-01-09 12:28:43 -05:00
:plugin-properties-files: {docdir}/../../buildSrc/src/main/resources
Docs: Prepare plugin and integration docs for 2.0 * Centralised plugin docs in docs/plugins/ * Moved integrations into same docs * Moved community clients into the clients section of the docs * Removed docs/community Closes #11734 Closes #11724 Closes #11636 Closes #11635 Closes #11632 Closes #11630 Closes #12046 Closes #12438 Closes #12579
2015-08-15 12:00:55 -04:00
The Elasticsearch repository contains examples of:
[Docs] Fix incomplete URLs (#28528)
2018-02-06 03:25:28 -05:00
* a https://github.com/elastic/elasticsearch/tree/master/plugins/examples/custom-settings[Java plugin]
Replace jvm-example by two plugin examples (#28339) This pull request replaces the jvm-example plugin (from the jvm/site plugins era) by two new plugins: a custom-settings that shows how to register and use custom settings (including secured settings) in a plugin, and rest-handler plugin that shows how to register a rest handler. The two plugins now reside in the plugins/examples project. They can serve as sample plugins for users, a special attention has been put on documentation. The packaging tests have been adapted to use the custom-settings plugin.
2018-01-26 11:34:24 -05:00
which contains a plugin with custom settings.
[Docs] Fix incomplete URLs (#28528)
2018-02-06 03:25:28 -05:00
* a https://github.com/elastic/elasticsearch/tree/master/plugins/examples/rest-handler[Java plugin]
Replace jvm-example by two plugin examples (#28339) This pull request replaces the jvm-example plugin (from the jvm/site plugins era) by two new plugins: a custom-settings that shows how to register and use custom settings (including secured settings) in a plugin, and rest-handler plugin that shows how to register a rest handler. The two plugins now reside in the plugins/examples project. They can serve as sample plugins for users, a special attention has been put on documentation. The packaging tests have been adapted to use the custom-settings plugin.
2018-01-26 11:34:24 -05:00
which contains a plugin that registers a Rest handler.
Add the ability to bundle multiple plugins into a meta plugin (#28022) This commit adds the ability to package multiple plugins in a single zip. The zip file for a meta plugin must contains the following structure: |____elasticsearch/ | |____ <plugin1> <-- The plugin files for plugin1 (the content of the elastisearch directory) | |____ <plugin2> <-- The plugin files for plugin2 | |____ meta-plugin-descriptor.properties <-- example contents below The meta plugin properties descriptor is mandatory and must contain the following properties: description: simple summary of the meta plugin. name: the meta plugin name The installation process installs each plugin in a sub-folder inside the meta plugin directory. The example above would create the following structure in the plugins directory: |_____ plugins | |____ <name_of_the_meta_plugin> | | |____ meta-plugin-descriptor.properties | | |____ <plugin1> | | |____ <plugin2> If the sub plugins contain a config or a bin directory, they are copied in a sub folder inside the meta plugin config/bin directory. |_____ config | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> |_____ bin | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> The sub-plugins are loaded at startup like normal plugins with the same restrictions; they have a separate class loader and a sub-plugin cannot have the same name than another plugin (or a sub-plugin inside another meta plugin). It is also not possible to remove a sub-plugin inside a meta plugin, only full removal of the meta plugin is allowed. Closes #27316
2018-01-09 12:28:43 -05:00
* a https://github.com/elastic/elasticsearch/tree/master/plugins/examples/rescore[Java plugin]
which contains a rescore plugin.
* a https://github.com/elastic/elasticsearch/tree/master/plugins/examples/script-expert-scoring[Java plugin]
which contains a script plugin.
Docs: Prepare plugin and integration docs for 2.0 * Centralised plugin docs in docs/plugins/ * Moved integrations into same docs * Moved community clients into the clients section of the docs * Removed docs/community Closes #11734 Closes #11724 Closes #11636 Closes #11635 Closes #11632 Closes #11630 Closes #12046 Closes #12438 Closes #12579
2015-08-15 12:00:55 -04:00
These examples provide the bare bones needed to get started. For more
information about how to write a plugin, we recommend looking at the plugins
listed in this documentation for inspiration.
[float]
=== Plugin descriptor file
Docs: Remove references to elasticsearch directory in plugins (#28647) This directory was removed from plugins in #28589, but docs still referenced it. This commit cleans up the plugin author docs to no longer refer to it.
2018-02-13 12:15:57 -05:00
All plugins must contain a file called `plugin-descriptor.properties`.
Add the ability to bundle multiple plugins into a meta plugin (#28022) This commit adds the ability to package multiple plugins in a single zip. The zip file for a meta plugin must contains the following structure: |____elasticsearch/ | |____ <plugin1> <-- The plugin files for plugin1 (the content of the elastisearch directory) | |____ <plugin2> <-- The plugin files for plugin2 | |____ meta-plugin-descriptor.properties <-- example contents below The meta plugin properties descriptor is mandatory and must contain the following properties: description: simple summary of the meta plugin. name: the meta plugin name The installation process installs each plugin in a sub-folder inside the meta plugin directory. The example above would create the following structure in the plugins directory: |_____ plugins | |____ <name_of_the_meta_plugin> | | |____ meta-plugin-descriptor.properties | | |____ <plugin1> | | |____ <plugin2> If the sub plugins contain a config or a bin directory, they are copied in a sub folder inside the meta plugin config/bin directory. |_____ config | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> |_____ bin | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> The sub-plugins are loaded at startup like normal plugins with the same restrictions; they have a separate class loader and a sub-plugin cannot have the same name than another plugin (or a sub-plugin inside another meta plugin). It is also not possible to remove a sub-plugin inside a meta plugin, only full removal of the meta plugin is allowed. Closes #27316
2018-01-09 12:28:43 -05:00
The format for this file is described in detail in this example:
Docs: Prepare plugin and integration docs for 2.0 * Centralised plugin docs in docs/plugins/ * Moved integrations into same docs * Moved community clients into the clients section of the docs * Removed docs/community Closes #11734 Closes #11724 Closes #11636 Closes #11635 Closes #11632 Closes #11630 Closes #12046 Closes #12438 Closes #12579
2015-08-15 12:00:55 -04:00
Fixed docs rendering of plugin-descriptor.properties in plugin author docs
2018-02-13 04:35:32 -05:00
["source","properties"]
Add the ability to bundle multiple plugins into a meta plugin (#28022) This commit adds the ability to package multiple plugins in a single zip. The zip file for a meta plugin must contains the following structure: |____elasticsearch/ | |____ <plugin1> <-- The plugin files for plugin1 (the content of the elastisearch directory) | |____ <plugin2> <-- The plugin files for plugin2 | |____ meta-plugin-descriptor.properties <-- example contents below The meta plugin properties descriptor is mandatory and must contain the following properties: description: simple summary of the meta plugin. name: the meta plugin name The installation process installs each plugin in a sub-folder inside the meta plugin directory. The example above would create the following structure in the plugins directory: |_____ plugins | |____ <name_of_the_meta_plugin> | | |____ meta-plugin-descriptor.properties | | |____ <plugin1> | | |____ <plugin2> If the sub plugins contain a config or a bin directory, they are copied in a sub folder inside the meta plugin config/bin directory. |_____ config | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> |_____ bin | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> The sub-plugins are loaded at startup like normal plugins with the same restrictions; they have a separate class loader and a sub-plugin cannot have the same name than another plugin (or a sub-plugin inside another meta plugin). It is also not possible to remove a sub-plugin inside a meta plugin, only full removal of the meta plugin is allowed. Closes #27316
2018-01-09 12:28:43 -05:00
--------------------------------------------------
[Docs] fix plugin properties inclusion for plugins authors
2018-01-09 18:00:27 -05:00
include::{plugin-properties-files}/plugin-descriptor.properties[]
Add the ability to bundle multiple plugins into a meta plugin (#28022) This commit adds the ability to package multiple plugins in a single zip. The zip file for a meta plugin must contains the following structure: |____elasticsearch/ | |____ <plugin1> <-- The plugin files for plugin1 (the content of the elastisearch directory) | |____ <plugin2> <-- The plugin files for plugin2 | |____ meta-plugin-descriptor.properties <-- example contents below The meta plugin properties descriptor is mandatory and must contain the following properties: description: simple summary of the meta plugin. name: the meta plugin name The installation process installs each plugin in a sub-folder inside the meta plugin directory. The example above would create the following structure in the plugins directory: |_____ plugins | |____ <name_of_the_meta_plugin> | | |____ meta-plugin-descriptor.properties | | |____ <plugin1> | | |____ <plugin2> If the sub plugins contain a config or a bin directory, they are copied in a sub folder inside the meta plugin config/bin directory. |_____ config | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> |_____ bin | |____ <name_of_the_meta_plugin> | | |____ <plugin1> | | |____ <plugin2> The sub-plugins are loaded at startup like normal plugins with the same restrictions; they have a separate class loader and a sub-plugin cannot have the same name than another plugin (or a sub-plugin inside another meta plugin). It is also not possible to remove a sub-plugin inside a meta plugin, only full removal of the meta plugin is allowed. Closes #27316
2018-01-09 12:28:43 -05:00
--------------------------------------------------
Docs: Prepare plugin and integration docs for 2.0 * Centralised plugin docs in docs/plugins/ * Moved integrations into same docs * Moved community clients into the clients section of the docs * Removed docs/community Closes #11734 Closes #11724 Closes #11636 Closes #11635 Closes #11632 Closes #11630 Closes #12046 Closes #12438 Closes #12579
2015-08-15 12:00:55 -04:00
Removed all references to site plugins from plugin docs
2016-04-12 13:28:09 -04:00
Either fill in this template yourself or, if you are using Elasticsearch's Gradle build system, you
Remove old reference to site plugins example in docs
2016-03-11 14:52:59 -05:00
can fill in the necessary values in the `build.gradle` file for your plugin.
Docs: Prepare plugin and integration docs for 2.0 * Centralised plugin docs in docs/plugins/ * Moved integrations into same docs * Moved community clients into the clients section of the docs * Removed docs/community Closes #11734 Closes #11724 Closes #11636 Closes #11635 Closes #11632 Closes #11630 Closes #12046 Closes #12438 Closes #12579
2015-08-15 12:00:55 -04:00
Enhance plugin-descriptor.properties guide * extract doc from the descriptor * make obvious that plugin authors will have to release a new version for each elasticsearch version
2015-10-05 04:13:02 -04:00
[float]
Plugins: Remove site plugins Site plugins used to be used for things like kibana and marvel, but there is no longer a need since kibana (and marvel as a kibana plugin) uses node.js. This change removes site plugins, as well as the flag for jvm plugins. Now all plugins are jvm plugins.
2016-01-17 00:54:05 -05:00
==== Mandatory elements for plugins
Enhance plugin-descriptor.properties guide * extract doc from the descriptor * make obvious that plugin authors will have to release a new version for each elasticsearch version
2015-10-05 04:13:02 -04:00
[cols="<,<,<",options="header",]
|=======================================================================
|Element | Type | Description
|`description` |String | simple summary of the plugin
|`version` |String | plugin's version
|`name` |String | the plugin name
|`classname` |String | the name of the class to load, fully-qualified.
|`java.version` |String | version of java the code is built against.
Use the system property `java.specification.version`. Version string must be a sequence
of nonnegative decimal integers separated by "."'s and may have leading zeros.
[Docs] Unify spelling of Elasticsearch (#27567) Removes occurences of "elasticsearch" or "ElasticSearch" in favour of "Elasticsearch" where appropriate.
2017-11-29 03:44:25 -05:00
|`elasticsearch.version` |String | version of Elasticsearch compiled against.
Enhance plugin-descriptor.properties guide * extract doc from the descriptor * make obvious that plugin authors will have to release a new version for each elasticsearch version
2015-10-05 04:13:02 -04:00
|=======================================================================
Docs: Remove references to elasticsearch directory in plugins (#28647) This directory was removed from plugins in #28589, but docs still referenced it. This commit cleans up the plugin author docs to no longer refer to it.
2018-02-13 12:15:57 -05:00
Note that only jar files at the root of the plugin are added to the classpath for the plugin!
Plugins: Remove site plugins Site plugins used to be used for things like kibana and marvel, but there is no longer a need since kibana (and marvel as a kibana plugin) uses node.js. This change removes site plugins, as well as the flag for jvm plugins. Now all plugins are jvm plugins.
2016-01-17 00:54:05 -05:00
If you need other resources, package them into a resources jar.
Enhance plugin-descriptor.properties guide * extract doc from the descriptor * make obvious that plugin authors will have to release a new version for each elasticsearch version
2015-10-05 04:13:02 -04:00
[IMPORTANT]
.Plugin release lifecycle
==============================================
[Docs] Unify spelling of Elasticsearch (#27567) Removes occurences of "elasticsearch" or "ElasticSearch" in favour of "Elasticsearch" where appropriate.
2017-11-29 03:44:25 -05:00
You will have to release a new version of the plugin for each new Elasticsearch release.
Enhance plugin-descriptor.properties guide * extract doc from the descriptor * make obvious that plugin authors will have to release a new version for each elasticsearch version
2015-10-05 04:13:02 -04:00
This version is checked when the plugin is loaded so Elasticsearch will refuse to start
in the presence of plugins with the incorrect `elasticsearch.version`.
==============================================
Docs: Prepare plugin and integration docs for 2.0 * Centralised plugin docs in docs/plugins/ * Moved integrations into same docs * Moved community clients into the clients section of the docs * Removed docs/community Closes #11734 Closes #11724 Closes #11636 Closes #11635 Closes #11632 Closes #11630 Closes #12046 Closes #12438 Closes #12579
2015-08-15 12:00:55 -04:00
[float]
Plugins: Removed plugin.types The setting `plugin.types` is currently used to load plugins from the classpath. This is necessary in tests, as well as the transport client. This change removes the setting, and replaces it with the ability to directly add plugins when building a transport client, as well as infrastructure in the integration tests to specify which plugin classes should be loaded on each node.
2015-08-22 03:21:13 -04:00
=== Testing your plugin
Docs: Prepare plugin and integration docs for 2.0 * Centralised plugin docs in docs/plugins/ * Moved integrations into same docs * Moved community clients into the clients section of the docs * Removed docs/community Closes #11734 Closes #11724 Closes #11636 Closes #11635 Closes #11632 Closes #11630 Closes #12046 Closes #12438 Closes #12579
2015-08-15 12:00:55 -04:00
When testing a Java plugin, it will only be auto-loaded if it is in the
Rename bin/plugin in bin/elasticsearch-plugin
2016-02-04 10:00:55 -05:00
`plugins/` directory. Use `bin/elasticsearch-plugin install file:///path/to/your/plugin`
Plugins: Removed plugin.types The setting `plugin.types` is currently used to load plugins from the classpath. This is necessary in tests, as well as the transport client. This change removes the setting, and replaces it with the ability to directly add plugins when building a transport client, as well as infrastructure in the integration tests to specify which plugin classes should be loaded on each node.
2015-08-22 03:21:13 -04:00
to install your plugin for testing.
You may also load your plugin within the test framework for integration tests.
Added link to test framework for plugin authors
2015-08-24 15:05:00 -04:00
Read more in {ref}/integration-tests.html#changing-node-configuration[Changing Node Configuration].
Docs: Prepare plugin and integration docs for 2.0 * Centralised plugin docs in docs/plugins/ * Moved integrations into same docs * Moved community clients into the clients section of the docs * Removed docs/community Closes #11734 Closes #11724 Closes #11636 Closes #11635 Closes #11632 Closes #11630 Closes #12046 Closes #12438 Closes #12579
2015-08-15 12:00:55 -04:00
Decentralize plugin security * Add ability for plugins to declare additional permissions with a custom plugin-security.policy file and corresponding AccessController logic. See the plugin author's guide for more information. * Add warning messages to users for extra plugin permissions in bin/plugin. * When bin/plugin is run interactively (stdin is a controlling terminal and -b/--batch not supplied), require user confirmation. * Improve unit test and IDE support for plugins with additional permissions by exposing plugin's metadata as a maven test resource. Closes #14108 Squashed commit of the following: commit cf8ace65a7397aaccd356bf55f95d6fbb8bb571c Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 13:36:05 2015 -0400 fix new unit test from master merge commit 9be3c5aa38f2d9ae50f3d54924a30ad9cddeeb65 Merge: 2f168b8 7368231 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:58:31 2015 -0400 Merge branch 'master' into off_my_back commit 2f168b8038e32672f01ad0279fb5db77ba902ae8 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:56:04 2015 -0400 improve plugin author documentation commit 6e6c2bfda68a418d92733ac22a58eec35508b2d0 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:52:14 2015 -0400 move security confirmation after 'plugin already installed' check, to prevent user from answering unnecessary questions. commit 08233a2972554afef2a6a7521990283102e20d92 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 05:36:42 2015 -0400 Add documentation and pluginmanager support commit 05dad86c51488ba43ccbd749f0164f3fbd3aee62 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 02:22:24 2015 -0400 Decentralize plugin permissions (modulo docs and pluginmanager work)
2015-10-14 14:46:45 -04:00
[float]
Rewrite the scripting security docs (#23930) They needed to be updated now that Painless is the default and the non-sandboxed scripting languages are going away or gone. I dropped the entire section about customizing the classloader whitelists. In master this barely does anything (exposes more things to expressions).
2017-04-07 11:46:41 -04:00
[[plugin-authors-jsm]]
Decentralize plugin security * Add ability for plugins to declare additional permissions with a custom plugin-security.policy file and corresponding AccessController logic. See the plugin author's guide for more information. * Add warning messages to users for extra plugin permissions in bin/plugin. * When bin/plugin is run interactively (stdin is a controlling terminal and -b/--batch not supplied), require user confirmation. * Improve unit test and IDE support for plugins with additional permissions by exposing plugin's metadata as a maven test resource. Closes #14108 Squashed commit of the following: commit cf8ace65a7397aaccd356bf55f95d6fbb8bb571c Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 13:36:05 2015 -0400 fix new unit test from master merge commit 9be3c5aa38f2d9ae50f3d54924a30ad9cddeeb65 Merge: 2f168b8 7368231 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:58:31 2015 -0400 Merge branch 'master' into off_my_back commit 2f168b8038e32672f01ad0279fb5db77ba902ae8 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:56:04 2015 -0400 improve plugin author documentation commit 6e6c2bfda68a418d92733ac22a58eec35508b2d0 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:52:14 2015 -0400 move security confirmation after 'plugin already installed' check, to prevent user from answering unnecessary questions. commit 08233a2972554afef2a6a7521990283102e20d92 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 05:36:42 2015 -0400 Add documentation and pluginmanager support commit 05dad86c51488ba43ccbd749f0164f3fbd3aee62 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 02:22:24 2015 -0400 Decentralize plugin permissions (modulo docs and pluginmanager work)
2015-10-14 14:46:45 -04:00
=== Java Security permissions
Some plugins may need additional security permissions. A plugin can include
Docs: Updated plugin author help for Gradle Relates to #15280
2015-12-15 06:27:20 -05:00
the optional `plugin-security.policy` file containing `grant` statements for
additional permissions. Any additional permissions will be displayed to the user
with a large warning, and they will have to confirm them when installing the
Decentralize plugin security * Add ability for plugins to declare additional permissions with a custom plugin-security.policy file and corresponding AccessController logic. See the plugin author's guide for more information. * Add warning messages to users for extra plugin permissions in bin/plugin. * When bin/plugin is run interactively (stdin is a controlling terminal and -b/--batch not supplied), require user confirmation. * Improve unit test and IDE support for plugins with additional permissions by exposing plugin's metadata as a maven test resource. Closes #14108 Squashed commit of the following: commit cf8ace65a7397aaccd356bf55f95d6fbb8bb571c Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 13:36:05 2015 -0400 fix new unit test from master merge commit 9be3c5aa38f2d9ae50f3d54924a30ad9cddeeb65 Merge: 2f168b8 7368231 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:58:31 2015 -0400 Merge branch 'master' into off_my_back commit 2f168b8038e32672f01ad0279fb5db77ba902ae8 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:56:04 2015 -0400 improve plugin author documentation commit 6e6c2bfda68a418d92733ac22a58eec35508b2d0 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:52:14 2015 -0400 move security confirmation after 'plugin already installed' check, to prevent user from answering unnecessary questions. commit 08233a2972554afef2a6a7521990283102e20d92 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 05:36:42 2015 -0400 Add documentation and pluginmanager support commit 05dad86c51488ba43ccbd749f0164f3fbd3aee62 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 02:22:24 2015 -0400 Decentralize plugin permissions (modulo docs and pluginmanager work)
2015-10-14 14:46:45 -04:00
plugin interactively. So if possible, it is best to avoid requesting any
spurious permissions!
[Docs] Unify spelling of Elasticsearch (#27567) Removes occurences of "elasticsearch" or "ElasticSearch" in favour of "Elasticsearch" where appropriate.
2017-11-29 03:44:25 -05:00
If you are using the Elasticsearch Gradle build system, place this file in
Decentralize plugin security * Add ability for plugins to declare additional permissions with a custom plugin-security.policy file and corresponding AccessController logic. See the plugin author's guide for more information. * Add warning messages to users for extra plugin permissions in bin/plugin. * When bin/plugin is run interactively (stdin is a controlling terminal and -b/--batch not supplied), require user confirmation. * Improve unit test and IDE support for plugins with additional permissions by exposing plugin's metadata as a maven test resource. Closes #14108 Squashed commit of the following: commit cf8ace65a7397aaccd356bf55f95d6fbb8bb571c Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 13:36:05 2015 -0400 fix new unit test from master merge commit 9be3c5aa38f2d9ae50f3d54924a30ad9cddeeb65 Merge: 2f168b8 7368231 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:58:31 2015 -0400 Merge branch 'master' into off_my_back commit 2f168b8038e32672f01ad0279fb5db77ba902ae8 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:56:04 2015 -0400 improve plugin author documentation commit 6e6c2bfda68a418d92733ac22a58eec35508b2d0 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 12:52:14 2015 -0400 move security confirmation after 'plugin already installed' check, to prevent user from answering unnecessary questions. commit 08233a2972554afef2a6a7521990283102e20d92 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 05:36:42 2015 -0400 Add documentation and pluginmanager support commit 05dad86c51488ba43ccbd749f0164f3fbd3aee62 Author: Robert Muir <rmuir@apache.org> Date: Wed Oct 14 02:22:24 2015 -0400 Decentralize plugin permissions (modulo docs and pluginmanager work)
2015-10-14 14:46:45 -04:00
`src/main/plugin-metadata` and it will be applied during unit tests as well.
Keep in mind that the Java security model is stack-based, and the additional
permissions will only be granted to the jars in your plugin, so you will have
write proper security code around operations requiring elevated privileges.
It is recommended to add a check to prevent unprivileged code (such as scripts)
from gaining escalated permissions. For example:
[source,java]
--------------------------------------------------
// ES permission you should check before doPrivileged() blocks
import org.elasticsearch.SpecialPermission;
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
// unprivileged code such as scripts do not have SpecialPermission
sm.checkPermission(new SpecialPermission());
}
AccessController.doPrivileged(
// sensitive operation
);
--------------------------------------------------
See http://www.oracle.com/technetwork/java/seccodeguide-139067.html[Secure Coding Guidelines for Java SE]
for more information.