GuestPolicy

# Language Settings: Policy

Guest "policies" define the access rights granted to a given guest language VM. Policies are defined by the host and
enforced at runtime.

## Policies: Allow-all.

Allows all host access for the guest language. This means the guest language can load classes, access I/O, and
perform other potentially sensitive or dangerous operations. Exercise extreme caution enabling this policy.

Whether to allow the guest language to call native code. Defaults to `false`.

Maximum execution time to allow for execution within this guest; there is a sensible Elide-wide default if
unspecified. Expressed in a count of milliseconds. `0` disables the restriction.

Whether to allow the guest language to access host-side environment. Defaults to `false`.

Whether to allow the guest language to access host-side I/O. Defaults to `false`.

Whether to allow the guest language to access host-side networking. Defaults to `false`.

## Policies: Integrated.

Allows some host access for the guest language; this includes values shared in callbacks and invocation bindings.
The guest language can only load certain classes, cannot access host I/O (by default), and is *allowed* to call
native code; this mode should be used when all executing code is under the developer's control.

## Policies: Isolated.

Allows no host access for the guest language. This means the guest language cannot load classes, access host I/O,
or perform other potentially sensitive or dangerous operations. Resources used by guest languages can be capped
or otherwise controlled.

Maximum memory to allow for allocation within this guest language; there is a sensible Elide-wide default if
unspecified. Expressed as a count of bytes. `0` disables the restriction.

Whether to allow process control for the guest; the guest will be able to launch OS-native processes if this flag
is activated. In most secure operating modes this flag defaults to being off.

## Policies: Sandbox.

Like the `ISOLATED` policy, but applies a stronger sandbox; allows no host access for the guest language. This
means the guest language cannot load classes, access host I/O, or perform other potentially sensitive or
dangerous operations. Resources used by guest languages can be capped or otherwise controlled.

If available, hardware isolation is used; otherwise, software isolation is used.

Maximum stack depth to allow for execution within this guest; there is a sensible Elide-wide default if
unspecified. Specified as a numeric count. `0` disables the restriction.

Whether to allow thread control for the guest; the guest will be able to launch OS-native threads if this flag is
activated. In most secure operating modes this flag defaults to being off.

## Policies: Allow-all.

Allows all host access for the guest language. This means the guest language can load classes, access I/O, and
perform other potentially sensitive or dangerous operations. Exercise extreme caution enabling this policy.

## Policies: Integrated.

Allows some host access for the guest language; this includes values shared in callbacks and invocation bindings.
The guest language can only load certain classes, cannot access host I/O (by default), and is *allowed* to call
native code; this mode should be used when all executing code is under the developer's control.

## Policies: Isolated.

Allows no host access for the guest language. This means the guest language cannot load classes, access host I/O,
or perform other potentially sensitive or dangerous operations. Resources used by guest languages can be capped
or otherwise controlled.

## Policies: Sandbox.

Like the `ISOLATED` policy, but applies a stronger sandbox; allows no host access for the guest language. This
means the guest language cannot load classes, access host I/O, or perform other potentially sensitive or
dangerous operations. Resources used by guest languages can be capped or otherwise controlled.

If available, hardware isolation is used; otherwise, software isolation is used.