Repository navigation
unshare-net fails on gvisor due to failing loopback setup #745
Description
I am running bwrap in a docker that runs on GCP, thus under gvisor.
When I try to use --unshare-all or --unshare-net, the bwrap code fails in:
if (opt_unshare_net)
loopback_setup (); /* Will exit if unsuccessful */
Is there a reason to try to setup loopback?
I have removed this code part and can confirm that then bwrap works on gvisor, too.
Thanks for any suggestion
Activity
smcv commentedon Apr 27, 2026
The existence of a
lointerface with address 127.0.0.1 and/or ::1 is "part of the API", and a lot of otherwise-non-networked software won't work correctly without it; it's the same reasoning as whyunshare-based Debian buildds providelo.Perhaps it would be OK to make
loopback_setup()failure non-fatal in the--unshare-netcase?norbusan commentedon Apr 28, 2026
Either that, or a cmd line option to enable/disable loopback setup would be great.
Thanks for your consideration.
enyonee commentedon Oct 19, 2026
Reproduced with bubblewrap 0.12.0 under
runsc release-20260914.0using:The fresh network namespace already has
loup at127.0.0.1/8. The exclusiveRTM_NEWADDRgetsNLMSG_ERROR -EEXIST; the printed errno can be stale.Proposed fix: #821. It skips setup only after verifying the exact required loopback state inside the newly created namespace. Query failures and mismatches keep the original setup and fatal errors.
The source fix backported to 0.12.0 passed four existing integration checks and six additional profile/loopback checks under that gVisor version as UID/GID 1000 with zero capabilities and
NoNewPrivs=1. The PR also adds 13 unit regression cases on current main. The full local Meson run passes both unit programs; five namespace integration programs skip in the ordinary Docker build environment, as documented in the PR.