Add environment variable to control host loopback (`DOCKERD_ROOTLESS_ROOTLESSKIT_DISABLE_HOST_LOOPBACK`)

[MadLittleMods]

Add environment variable to control host loopback (DOCKERD_ROOTLESS_ROOTLESSKIT_DISABLE_HOST_LOOPBACK)

Based on moby/moby -> contrib/dockerd-rootless.sh#L24-L25 (added in https://github.com/moby/moby/pull/47352).

---

This kind of workaround is mentioned in various places like https://stackoverflow.com/questions/72500740/how-to-access-localhost-on-rootless-docker.

Our actual use case is setting up some self-hosted GitHub runners with a rootless Docker-in-Docker setup which works fine except that nested containers created within the runner container are unable to contact host.docker.internal (Connection refused). (using actions/actions-runner-controller (docs)). With this change, we plan to map host.docker.internal:10.0.2.2 and does seem to work.

[tianon]

I don't love the idea of maintaining more lines/complexity here -- as I've noted over in https://github.com/docker-library/docker/pull/543#pullrequestreview-2977057367, I'm not actually convinced continuing to maintain the rootless variant (still labelled on Docker Hub as "experimental" :sweat_smile:) makes sense.

[Arkaniad]

I don't love the idea of maintaining more lines/complexity here -- as I've noted over in #543 (review), I'm not actually convinced continuing to maintain the rootless variant (still labelled on Docker Hub as "experimental" 😅) makes sense.

Is there a way to configure the regular dind image to behave as the dind-rootless image does at runtime? If so, then possibly not - but most of the documentation I've found pertaining to rootless DinD setups specifically points out this image as necessary for it to work.

As @MadLittleMods mentioned, the key thing we are trying to accomplish is communication from guest containers to a process running in the host container to co-ordinate some testing. Investigation along these lines seems to indicate that for what we want to do, we'll need slirp4netns, which only seems to be built into the rootless variant. As well we'd like to enable loopback communication selectively in this configuration, which seems to be not possible without this MR's changes (unless there's a less-obvious way to toggle this switch in rootlesskit at runtime)

[Arkaniad]

I guess, to rephrase, when you say the rootless variant doesn't provide much security benefit - Does that mean none at all, or maybe a little? It's totally possible that cargo-cult advice has led to this images use for our case.

In our use scenario, we've found that using the rootless variant image allows us to mitigate an issue we found via internal security testing that let us escape a self-hosted dind build runner and obtain AWS IAM credentials from a CI workflow.