Granting permissions to third-party JAR in lib/ — is patching security.policy inside opensearch-3.2.0.jar the right approach?

Security
1

I am embedding a third-party logging JAR (logagent.jar) into OpenSearch 3.2.0 by placing it in lib/. The JAR needs SocketPermission to connect to an external HTTPS endpoint.

I found that OpenSearch’s agent-based security (ByteBuddy instrumentation via opensearch-agent.jar) reads org/opensearch/bootstrap/security.policy embedded inside opensearch-3.2.0.jar. Since logagent.jar has no entry in that file, its ProtectionDomain is empty and all socket connections are denied with "Denied access to: <host>:443".

Standard -Djava.security.policy JVM flag is ignored. Plugin plugin-security.policy doesn’t apply to lib/ JARs. Disabling the Security Manager via JVM flags crashes OpenSearch startup.

My current fix: Extract org/opensearch/bootstrap/security.policy from opensearch-3.2.0.jar, append:

```
grant codeBase “${codebase.logagent.jar}” {
permission java.net.SocketPermission “*”, “connect,resolve”;
…
};
```
then repack the JAR. Automated in our build pipeline.

We also tried placing logagent.jar in plugins/logagent/ with a plugin-security.policy. This failed for two reasons:
(1) JarHell — if logagent.jar exists in both lib/ and plugins/, OpenSearch refuses to start due to duplicate classes.
(2) If removed from lib/ entirely, Log4j2 initializes at bootstrap (LogConfigurator.configure() in Bootstrap.init()) before plugins are loaded, so it cannot find the custom appender type and all appenders fail with Unable to locate plugin type. The JAR must be in lib/ for Log4j2, but lib/ JARs get no permissions from the plugin policy mechanism.

Question: Is there any supported/official way to extend OpenSearch’s security policy for third-party JARs in lib/ without patching the main JAR? Or is the JAR patch the only path?

2

I also considered a plugin-only workaround, although I have not tested it end to end.

The idea is to:

  1. Keep the third-party logging JAR only under plugins//, avoiding JarHell.
  2. Grant its network access through plugin-security.policy
  3. Remove the custom appender from the bootstrap log4j2.properties.
  4. After the plugin loads, programmatically create and attach the appender to the running Log4j2 LoggerContext, possibly from ClusterPlugin.onNodeStarted().

Conceptually:

LoggerContext context = (LoggerContext) LogManager.getContext(false);
Configuration config = context.getConfiguration();

Appender appender = createThirdPartyAppender();
appender.start();

config.addAppender(appender);
config.getRootLogger().addAppender(appender, Level.INFO, null);
context.updateLoggers();

This should avoid both problems: the JAR exists in only one location, and Log4j2 does not need to discover the appender during bootstrap.

Has anyone tried this approach in an OpenSearch plugin? Is there any tradeoffs or cons I should know about before going through with this?