Remove SecurityManager

[reta]

It has been announced a while ago that SecurityManager is going to be phased out from the JDK. The first step, the deprecation of the SecurityManager (JEP-411), has been landed in JDK 17 and issues the following warnings on OpenSearch builds or server startup:

WARNING: System::setSecurityManager will be removed in a future release

The JDK 18 pushes it even further and now fails on startup (see please https://bugs.openjdk.java.net/browse/JDK-8270380), running OpenSearch builds or server on JDK 18 EA fails with:

Caused by: java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release
	at java.base/java.lang.System.setSecurityManager(System.java:416)

What is the problem? What is preventing you from meeting the requirements?
The OpenSearch primary protection mechanism against plugins abuse or misuse is built on top of SecurityManager. It is very likely, it is going to be removed from the JDK-19+.

What are you proposing? What do you suggest we do to solve the problem or improve the existing situation?
There is no alternative or replacement for the SecurityManager. One of the options is to just drop it, it might be considered risky but combined with Plugin Sandbox (see please [1], [2]) it may sounds like a viable option.

What are your assumptions or prerequisites?
It would be great to have Plugin Sandbox design (and ideally, implementation) finalized.

What are remaining open questions?
Basically, the main question is to drop or to replace (bytecode instrumentation? custom classloaders? java agent?).

OpenSearch

• [RFC] Replace Java Security Manager (JSM) OpenSearch#1687

Plugins

• TODO: open issue for each plugin once the decision is made

[1] opensearch-project/OpenSearch#1572
[2] opensearch-project/OpenSearch#1422

[reta]

@dblock done, sorry but cannot add labels to it, whenever you have time please

[nknize]

I suspect the surface area of this will be quite large. I'd be okay targeting 3.0.0?

[reta]

@nknize we could mark it as 2.0.0 but make a decision to postpone to 3.0.0 if indeed we are not ready

[dblock]

I'm not creating a 3.0 label yet, but I removed untriaged. Thanks!