This bug is basically a duplicate of #903635.
On Tuesday, 27 November 2018 9:00:20 AM AEDT Marvin Renich wrote:
> HUH??? Since when is it okay for software that is not advertised as
> firewall software to modify the sysadmin's implicit or explicit iptables
> setup for IP packets completely unrelated to said software?
>
> I understand that this is a non-trivial problem because of the history
> behind /proc/sys/net/ipv4/ip_forward and the FORWARD chain, but docker
> can and needs to do better. My first approximation would be to only
> change the policy for FORWARD if ip_forward was 0 before docker added
> its own iptables rules. This will probably work 99.9% of the time.
>
> The current behavior appears to break other software 100% of the time
> if that software relies on ip_forward being 1 and the FORWARD chain
> being in its default state.
Situation is unfortunate and upstream does not care enough. They probably
want Docker users to use Docker exclusively without any other software on the
host. I very much dislike this approach but that's Docker for you... :(
About 6 months ago I've moved all my application containers from Docker to
"rkt" and I couldn't be happier. Although still immature, in the future
libpod/podman will likely become a worthy Docker successor.
> I'm raising this back to critical (makes unrelated software on the
> system break), as I cannot fathom how this could not be broken for
> anyone using KVM with a bridging network interface unless they have
> found one of the workarounds given in this thread (i.e. the
> /etc/docker/daemon.json modification, or manually modifying the FORWARD
> chain).
I'm lowering severity back to "important". You are not wrong that Docker is
hostile to other applications but I think many users would agree that we need
Docker in "testing" and upcoming Debian release despite of this problem.
--
All the best,
Dmitry Smirnov.
---
Truth never damages a cause that is just.
-- Mahatma Gandhi
signature.asc
Description: This is a digitally signed message part.
