[Bug] Gremlin sandbox blocks HStore gRPC allocator configuration reads #3412

Bug Type

Other exception / error: HStore access during Gremlin evaluation.

Environment

• Observed during HStore readiness on Linux/JDK17, with HugeSecurityManager enabled and grpc-netty-shaded 1.47.0. The graph had not been populated.
• Independently reproduced against current master f04d5cc8fc2fbd849d6aeef3f111e717a1f8f90d (1.8.0), using its actual grpc-netty-shaded 1.55.3 dependency, GremlinGroovyScriptEngine, and JVM security manager on Temurin 17.0.20.1/macOS aarch64.

Expected and actual behavior

A Gremlin query that reads HStore should be able to initialize an internal gRPC transport while script access to system properties remains restricted.

Instead, the first Gremlin read requiring a new transport fails with HTTP 500 and a gRPC channel panic:

java.lang.SecurityException: Not allowed to access system property(io.grpc.netty.shaded.io.grpc.netty.useCustomAllocator) via Gremlin
    at org.apache.hugegraph.security.HugeSecurityManager.newSecurityException(...)
    at org.apache.hugegraph.security.HugeSecurityManager.checkPropertyAccess(...)
    at java.base/java.lang.System.getProperty(...)
    at io.grpc.netty.shaded.io.grpc.netty.Utils.getByteBufAllocator(...)

io.grpc.StatusRuntimeException: INTERNAL: Panic! This is a bug!

Reproduction and cause

1. Start a server backed by HStore with the existing security manager enabled.
2. Submit a Gremlin read such as g.V().limit(1).hasNext() that requires a new HStore gRPC transport. No large dataset or application schema is required.
3. Observe the allocator-property rejection above and the failed query.

Gremlin evaluation -> HStore scan -> new gRPC transport
    -> Utils.getByteBufAllocator(boolean)
    -> System.getProperty("io.grpc.netty.shaded.io.grpc.netty.useCustomAllocator", "true")
    -> HugeSecurityManager rejects the internal read

The allocator reads this property on every invocation, so warming gRPC before Gremlin evaluation does not prevent the failure on later connections.

A focused regression also reproduces the rejection without starting a database or opening a connection: initialize the actual allocator, then invoke it through GremlinGroovyScriptEngine.eval() under HugeSecurityManager on a gremlin-server-exec-* or task-worker-* thread. Both worker paths fail on unmodified master. Calling CompiledScript.eval() directly is insufficient for this reproduction because it omits the engine stack frame used to identify Gremlin.

Proposed fix and verification boundary

Add this exact, non-sensitive boolean configuration flag to the existing property-read whitelist. Direct Gremlin script reads of this one flag are also permitted. Keep sensitive and unrelated property reads and bulk system-property enumeration denied; grant no wildcard access to the gRPC namespace. This avoids coupling production permission checks to a gRPC internal class or method name.

Fix PR: #3413. It includes actual-JAR regression coverage for both worker types and heap/direct allocators, permitted direct flag reads, and the remaining script-denial checks. The exact policy is documented in docs/server-runtime.md. This component reproduction does not establish full distributed HStore integration or benchmark acceptance.

Searched existing issues and PRs for the property and HStore/security-manager failures. Related #3214 concerns denied worker creation during ordered scans; this failure concerns an internal allocator-property read.