Status

Current state: Under DiscussionAccepted, being implemented

Discussion thread: https://lists.apache.org/thread/7qqknryoh4hxv2s7291j8g5shlcbock3

JIRA:  

Released: <Solr Version> Solr 10.x (TBD)

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast). Confluence supports inline comments that can also be used.

Motivation

Java Security Manager is gone from (JSM) was permanently removed in Java 24 . Solr will then run unprotected without sandboxing file access etc. It would make sense to implement some protection in chosen areas, as also e.g. OpenSearch has done(JEP 486). Solr previously relied on JSM to sandbox plugin code at runtime — restricting unauthorized file access, outbound network connections, System.exit() calls, and child process spawning. Without a replacement, Solr running on Java 24+ provides no runtime enforcement of these protections, leaving the JVM and any loaded plugin code unconstrained.

The OpenSearch project faced the same problem and solved it for OpenSearch 3.0 using a Java agent based on ByteBuddy instrumentation. See their write-up and the agent-sm source (Apache 2.0). This SIP proposes to use and adapt this approach.

Public Interfaces

The proposal will likely lead to some new configuration options to tailor the new features. Also the old SecurityProfile files will be gone.

Proposed Changes

We will not re-implement JSM, but a minimum of low-hanging protection mechanisms can be considered:

• Limit what file paths can be read/written
• Limit certain network access can be made
• Prevent System.exit()
• Limit Process exec to a limited set of classes
• etc

following new operator-facing interfaces are introduced:

• Agent JAR — server/lib/ext/solr-agent-sm-*.jar, loaded automatically via -javaagent: by the startup scripts when present.
• Default policy file — server/etc/agent-security.policy (JDK-style .policy syntax; ships with Solr; not intended for operator editing).
• Operator extension file — server/etc/agent-security-extra.policy (optional; absent is non-fatal; entries tagged source=OPERATOR in violation logs).
• Environment variables — SOLR_SECURITY_AGENT_MODE=warn|enforce (default: warn) and SOLR_SECURITY_AGENT_SKIP=true to disable.
• Violation metrics — per-type counters at /admin/metrics under security.agent.violations.file, .network, .exit, .exec.
• Deprecations — SolrPaths.assertPathAllowed() deprecated for new callers; existing JSM security.policy and solr-tests.policy files marked deprecated.

Proposed Changes

A new Gradle subproject solr/agent-sm/ will be created, producing a standalone Java agent JAR adapted from the Apache 2.0-licensed OpenSearch libs/agent-sm. The agent uses ByteBuddy @Advice instrumentation and StackWalker (Java 9+) to intercept JDK APIs at the bytecode level — applying to all code in the JVM including plugins, without requiring any code changes. It is virtual-thread safe (no thread-identity assumptions).

Four protection categories:

• File access — reads and writes restricted to configured Solr directories. Windows UNC paths (\\host\share) unconditionally blocked. Symlinks resolved to real path before policy check.
• Network access — outbound connections restricted to a permitted endpoint list. The default policy permits loopback addresses and all intra-cluster Solr and ZooKeeper traffic using port-based wildcards (*:<solr.port>, *:<zk-port>), covering all cluster nodes regardless of join order.
• JVM shutdown — System.exit() and Runtime.halt() restricted to an approved call-site list (SolrCLI, SolrDispatchFilter by default).
• Process execution — ProcessBuilder.start() and Runtime.exec() restricted to an approved call-site list (empty by default in production).

The initial release will use warn-only mode — violations are logged but operations are not blocked. Operators opt into enforce mode via SOLR_SECURITY_AGENT_MODE=enforce. A future release will flip the default.

Policy files use standard JDK .policy syntax extended with Solr variable substitution (${solr.home}, ${solr.port}, ${solr.zk.port}, etc.). The operator extension file ships with commented-out examples for all known modules that require external network access (jwt-auth, extraction/Tika, opentelemetry, s3-repository, gcs-repository, cross-dc-manager).

For a detailed specification and implementation plan - generated by Github's SpecKit, see http://cominvent.com/pub/jsm-spec.html.Please see https://opensearch.org/blog/finding-a-replacement-for-jsm-in-opensearch-3-0/ for a description on the approach chosen by the Opensearch project. Their java agent can be found here https://github.com/opensearch-project/OpenSearch/tree/main/libs/agent-sm

Compatibility, Deprecation, and Migration Plan

• JSM is going away, which will impact users anyway, removal in Java 24 is mandatory and outside Solr's control (see

  Jira
  server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key SOLR-17641

  which is the Jira to disable — startup scripts disable the security manager when flag on Java >= 24 is detected by start scripts. 
• The new protections can be a subset of existing JSM rules, so Solr should not stop running if it runs today under JSM
• Most users will not see any change
• There will not be any action required by users

Security considerations

This SIP will harden Solr's security after JSM goes away in Java 24.

Test Plan

...

• ≥ 24).
• The default policy covers standard Solr directory layouts and intra-cluster traffic. Most deployments will require no configuration changes.
• Warn-only default ensures zero disruption on upgrade. Operators can review violation logs before enabling enforce mode.
• Modules that connect to external services (OIDC, OTLP, S3, GCS, Kafka, remote Tika) may require operator-added policy entries in enforce mode. Consider each one. Perhaps only those with a user-injected URL must be manually added?
• The existing server/etc/security.policy and solr-tests.policy JSM files are deprecated and retained as migration reference only; they are not enforced by the JVM on Java 24+.
• SolrPaths.assertPathAllowed() is deprecated for new callers; existing call sites are retained as defense-in-depth.

Security Considerations

This SIP restores runtime sandboxing for Solr on Java 24+ after JSM removal. Key points:

• All code in the JVM — including third-party plugins — is subject to enforcement without any plugin-side changes required.
• The agent runs in the JVM bootstrap classloader; it cannot be bypassed by application-level classloader manipulation.
• Intra-cluster network policy uses port-based wildcards rather than a host list, which is intentional: inter-node Solr HTTP is already PKI-authenticated, and a host list derived at startup would always be incomplete as nodes join incrementally.
• Warn-only default is a deliberate trade-off to avoid regressions in the plugin ecosystem; it does not reduce security versus the current state (no enforcement at all on Java 24+).

Test Plan

• Unit tests for PolicyLoader — variable substitution, merging, error handling.
• Interceptor unit tests for each protection category — permitted operations succeed, violations blocked/logged, counters increment.
• Full-stack integration test (SolrAgentIntegrationTest) running in enforce mode — all four protection categories exercised.
• Existing JSM-related tests repurposed where applicable.
• Virtual thread compatibility test suite — no false positives or negatives under Project Loom.
• Broader Solr integration suite run in warn mode to detect unexpected violations before the enforce-mode flip in a future release.

Rejected Alternatives

• Staying on < Java24Java < 24 — not viable long-term; Solr must support current Java LTS releases.
• Removing JSM protections without any replacement — unacceptable security regression.
• OS-level hardening only (systemd, seccomp) — not cross-platform; does not cover Windows or macOS.
• Dynamic ZK-watcher-based network policy — correct but significantly more complex; adds ZK client dependency to the agent JAR. Superseded by port-based wildcards for intra-cluster traffic.
• Building a Java agent from scratch — higher effort with no functional advantage over adapting the Apache 2.0-licensed OpenSearch implementation.