Package com.tnsai.quality.sandbox
Class ProcessSandbox
java.lang.Object
com.tnsai.quality.sandbox.ProcessSandbox
- All Implemented Interfaces:
Sandbox,AutoCloseable
Portable
Sandbox backend using JVM ProcessBuilder
(TNS-296). The fallback that runs everywhere — slower than
container/microVM/WASM backends but available on every host.
Provides
- Process boundary — child code does not share in-process JVM heap references. This backend does not provide OS-level process isolation against same-user attach, tracing, or host-kernel capabilities.
- Per-instance temporary working directory.
- Env scrubbing — only
SandboxSpec.env()entries are visible to sandboxed processes; the host's environment is not inherited. - Timeout enforcement —
Process.waitFor(long, TimeUnit)with the spec'sResourceLimits.timeout(); over-budget processes are killed andSandboxResult.timedOut()is set. - Host-heap output cap — combined stdout+stderr cannot exceed
ResourceLimits.maxOutputBytes(); overflow kills the child and setsSandboxResult.outputTruncated(). - Wall-clock accounting —
ResourceUsage.wallClockMs.
Cannot provide (use a stronger backend)
- Filesystem isolation or mounts. The temporary working directory is only
passed to
ProcessBuilder.directory(java.io.File); it is not a chroot, namespace, or path interceptor. Child processes can still read and write host paths permitted to the JVM user. UseContainerSandboxor a stronger backend when filesystem confinement orFsMountmappings are required. This backend rejects every non-emptySandboxSpec.fsMounts()request rather than silently changing an absolute sandbox path into a relative copy. - Network policy enforcement.
NetPolicy.DenyAllandNetPolicy.AllowListare recorded but not enforced by this backend; a JVM child process inherits the host network stack. The factory logs a warning at creation time. For real network isolation useContainerSandboxorFirecrackerSandbox. - CPU / memory caps. The JVM has no portable way to limit a child process's resources; backends backed by cgroups or container runtimes do this properly.
- Since:
- 0.10.0 (TNS-296)
-
Method Summary
Modifier and TypeMethodDescriptionRuncommandto completion (or until the sandbox kills it for exceedingResourceLimits.timeout).spec()TheSandboxSpecthis instance was created from.voidstop()Graceful shutdown.voidForcibly kill the sandbox and release its resources.
-
Method Details
-
spec
Description copied from interface:SandboxTheSandboxSpecthis instance was created from. Useful for downstream tooling (audit, observability) that needs to record the configured policy alongside the result. -
execute
Description copied from interface:SandboxRuncommandto completion (or until the sandbox kills it for exceedingResourceLimits.timeout). Always returns aSandboxResult; failures inside the sandbox are reflected inSandboxResult.exitCodeandSandboxResult.stderr, not thrown.Throws if the sandbox itself has been terminated, or if the backend layer cannot dispatch the command (image missing, runtime crash). Those are infrastructure failures, distinct from "the user's command exited non-zero".
-
stop
public void stop()Description copied from interface:SandboxGraceful shutdown. Backends SHOULD send SIGTERM (or the platform equivalent), wait a short grace period, then promote toSandbox.terminate()if the process is still running. -
terminate
public void terminate()Description copied from interface:SandboxForcibly kill the sandbox and release its resources. Idempotent — calling on an already-terminated sandbox is a no-op. Safe infinallyblocks.
-