mirror of
https://github.com/lima-vm/lima.git
synced 2026-10-28 11:44:35 +08:00
Rana Md Ali Ahsan
c388098fae
The default user-mode network maps the gateway IP to the host's 127.0.0.1, so the guest can reach every host service via `host.lima.internal`, including ones bound only to the loopback. That is useful for dev VMs but exposes local databases and dev servers to a guest that runs untrusted code, such as a CI runner. Add `networkOpts.hostLoopback` to lima.yaml (default true, unchanged), in a new `networkOpts` group for network options. When false, the in-process gvisor-tap-vsock gateway maps the gateway IP and 0.0.0.0 to 0.0.0.1 instead of 127.0.0.1. The host has no route to 0.0.0.1, so connections to `host.lima.internal` are refused at once, rather than going to the host's LAN, and UDP to 0.0.0.0 cannot reach the host's loopback either. DNS, outbound access and SSH are unaffected. Only `vmType: vz` supports it. `qemu`, `krunkit`, `wsl2` and `hcs` reject `false` rather than ignore it (krunkit's default host resolver sends DNS through `host.lima.internal`, so it needs separate work), and so does a `user-v2` network, which is a daemon shared by instances. The refusals are in each driver's Validate, not in validateConfig, which Configure also runs on deletion. A proxy on the host's loopback, whether it comes from the host's network settings, `env`, or `propagateProxyEnv`, is rewritten to the gateway address, which `networkOpts.hostLoopback: false` makes unreachable. Lima warns when that happens, and the docs say so. A BATS test, run in the vz CI job, checks end to end that a host loopback service is refused at once with `false` and reachable after switching to `true`, that DNS keeps working, and that a `user-v2` network is rejected. Refs #5574 Assisted-by: Claude Code Signed-off-by: Rana Md Ali Ahsan <rana@codesamplez.com>