Silently skips a plugin's entire plugin-security.policy grant when the file is packaged inside the jar instead of at the plugin root

Is your feature request related to a problem?

A plugin's plugin-security.policy is only honored when it's placed at the root of the plugin zip, as a sibling of the plugin's jar(s) (via the Gradle convention src/main/plugin-metadata/plugin-security.policy for plugins built with opensearch.opensearchplugin). Security.getPluginPermissions() looks for it there:

https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/bootstrap/Security.java#L199-L235

Path policyFile = plugin.resolve(PluginInfo.OPENSEARCH_PLUGIN_POLICY);
if (Files.exists(policyFile)) {
    ...
}

If a plugin author instead bundles plugin-security.policy as a regular classpath resource inside their jar (an easy, natural mistake — e.g. via Gradle's src/main/resources/, since that's the normal place to put a file you want packaged with your code), Files.exists(policyFile) is false, and this method silently skips that plugin's directory entirely. None of the plugin's declared permissions are granted — not just the malformed/misplaced parts, all of them — with zero warning or log line anywhere.

The plugin then fails at runtime with a generic, misleading SecurityException: Denied access to: <host>:<port>, domain ProtectionDomain (...), which reads exactly like a "you forgot to declare this permission" error even though the permission was declared correctly — it just never got loaded. This sent us chasing the wrong root cause for a while (initially suspected an OpenSearch core/agent bug, see Vinz2168/opensearch-monitoring-exporter#4) before finding the actual issue was our own plugin's packaging.

One extra, confusing wrinkle: opensearch-plugin install itself does correctly read the zip-root policy file and prints the "plugin requires additional permissions" banner at install time when the file is in the right place — so the install-time UX actually gives a correct signal, while the runtime silently diverges from it when the packaging is wrong. In our case, the banner never appeared during install (a discoverable clue in hindsight), but nothing at runtime ever pointed back to it.

What solution would you like?

When Security.getPluginPermissions() walks each plugin/module directory and does not find plugin-security.policy there, additionally check whether any of that plugin's jars contain a plugin-security.policy entry at their root (a cheap ZipFile/JarFile entry lookup, no need to parse it). If one is found, log a WARN at node startup along these lines:

plugin [<name>] contains a plugin-security.policy inside its jar (<jar>), but not at
the plugin's root directory. This file will NOT be applied -- OpenSearch only reads
plugin-security.policy from the plugin's install root (see plugin-metadata packaging
convention). None of this plugin's declared permissions have been granted.

This turns a silent, total loss of a plugin's declared permissions (surfacing later as confusing SecurityExceptions during actual operation, potentially minutes or requests later) into an immediate, actionable startup-time warning pointing at the actual mistake.

What alternatives have you considered?

• Leaving it as-is and relying on plugin authors reading the packaging docs carefully. This is what caused the confusion here; the failure mode gives no hint that packaging (rather than the policy's content) is the problem.
• A stricter option — failing plugin load entirely when this mismatch is detected — but a WARN seems more appropriate: it's not certain the plugin needs the missing grants (though a mismatch like this is never intentional), and a hard failure would be a bigger behavior change for what's meant to be a diagnostics improvement.

Do you have any additional context?

Found and root-caused via a real repro against opensearchproject/opensearch:3.7.0, confirmed with temporary diagnostic logging patched into OpenSearchPolicy.implies(): plugins.get(location.getFile()) returned mapHit=false for the affected plugin's jar specifically (780 other plugin-jar entries were present and correctly matched on the same node), while the plugin's plugin-security.policy was demonstrably present — just inside the jar instead of at the plugin root. Moving the file to src/main/plugin-metadata/ and reinstalling resolved it immediately, with a fully stock, unpatched OpenSearch core.

Start in server/src/main/java/org/opensearch/bootstrap/Security.java around Security.getPluginPermissions() and trace how each plugin directory and its jars are inspected. Confirm the behavior for a policy at the plugin root versus inside a jar, then add coverage for the requested startup warning when only the jar-contained policy is found.