opensearch-project/OpenSearch#17181 proposes turning off the Security Manager in the 3.0 release of OpenSearch. On 08/02/25, based on community feedback, we reached a consensus to proceed with the deprecation. The deprecation requires building two replacement alternatives [1] and [2]. While [1] has already been merged, [2] is at risk of missing delivery given the 3.0.0 Beta timelines.

To fully implement the two agreed alternatives, we think the launch of 3.0-Beta would needs to be delayed by 2 weeks. It is also very likely that this Beta delay will push the GA release by the same number of weeks.

This proposal is to get an approval from TSC for this extension.

[1] Systemd strengthening: leveraging operating system (linux) security primitives.

[2] Java Agent: A platform-independent component that can intercept socket and file operations and enforce, at the plugin level, whether a plugin is allowed to perform socket or file operations.

Meta Issues

• Permanently turn-off Security Manager (JSM) starting 3.0 OpenSearch#17181
• [Security Manager Replacement] Strengthen OS core security via systemd configuration  OpenSearch#16729
• [POC] [Security Manager Replacement] Native Java Agent (dynamic code rewriting, must be low overhead) OpenSearch#16731

Why do we want to turn-off JSM in 3.0?

[1] JDK 21 introduces virtual threads, based on: JEP 444: Virtual Threads, "Virtual threads have no permissions when running with a SecurityManager set." This means that any code using virtual threads under a Security Manager will not work. While OpenSearch 3.0 itself will not contain virtual threads, we anticipate that developers—especially plugin developers—will want to leverage them in future 3.x versions. To support this, we could consider disabling the Security Manager in a later 3.x release. There is a strong argument for not deprecating a security feature unless absolutely necessary. However, deprecating such a significant security feature in a minor version release is generally not acceptable. An alternative approach could be to introduce a new major version (4.0) with the Security Manager disabled. However, it is too early to predict the lifecycle of major versions, as they tend to last a long time (for example, the 2.x series lasted around two years).

Are there any security considerations?

We necessarily want both alternatives [1] and [2] to be released before turning off the Security Manager. Releasing just one of them is not an option. The delivery of [2], which is causing the delay, is needed because it is platform-independent and the only available alternative for non-Linux platforms. Additionally, [2] can enforce restrictions at the plugin level, whereas [1] operates only at the OS layer.

However, a delay of a new release will not have any security implications.

What is the primary alternative plan of action in lack of TSC agreement/approval.

The alternative plan could be to introduce the disablement of the Security Manager in version 4.0. Once the development of [2] (Java Agent) is completed, a new proposal for a major version release will be filed. This release could be dedicated to Security Manager disablement but may also introduce other breaking changes that could not make it into 3.0. This new major release would be faster than a typical major release cycle, with the trade-off that we do not want developers to be blocked from leveraging virtual threads.

Generally, a major version release has higher developer work cycles as compared to minor version releases. Given that we are only asking for a two-week extension, we propose to deliver this feature within the current release cycle rather than deferring it to a future major release. We would want to hear from TSC the implication of delay to their software and company.

What users have asked for this feature?

The feature (turn-off of security manager) has been widely upvoted by the community maintainers.

• Permanently turn-off Security Manager (JSM) starting 3.0 OpenSearch#17181