search

elastic / elasticsearch

Free and Open Source, Distributed, RESTful Search Engine
https://www.elastic.co/products/elasticsearch
Other
771 stars 24.79k forks source link

Lock down cli scripts classpath #29177

Open rjernst opened 6 years ago

rjernst commented 6 years ago

The cli scripts currently all use a * classpath of the lib directory in the elasticsearch installation. This means not only the jars that come with elasticsearch, but any others that are dropped into the lib dir, will be used. This issue is to discuss building explicit classpaths at distribution build time, which explicitly list the jars we ship with. Based on the outcome of #29176, we would also dynamically add jars based on the value of an additional classpath environment variable.

One feature this will enable is separating some jars for the modulepath when in java 9+.

elasticmachine commented 6 years ago

Pinging @elastic/es-core-infra

rjernst commented 6 years ago

We discussed this in the core team meeting and agreed I will do this on master for 7.0 only, once #29176 is complete.

williamrandolph commented 5 years ago

Note that the blocking ticket referenced above has been closed in favor of #29306, which is still open.

pugnascotia commented 2 years ago

@rjernst is this still valid, now that startup happens in Java?

rjernst commented 2 years ago

The move to Java CLIs didn't change the classpath. We did, however, change to using the modulepath. It is marginally better, in that we declare the root module we use, and all of its dependencies are found via the modulepath, but arbitrary modules are not loaded. To achieve the lockdown I envisioned here, we would have to ensure plugins cannot depend on any modules from the modulepath. This may already be the case. A step further would be to detect when unknown modules exist, but I'm not sure how we would do that with the modulepath.

/cc @ChrisHegarty