[I'm subscribed to this bug, you don't need to include me in TO or CC.]
* Dmitry Smirnov <only...@debian.org> [181126 20:45]:
> This bug is basically a duplicate of #903635.
Not really. Bug #903635 is about not obeying a documented command line
option. This bug is about incorrectly modifying iptables when it is
enabled. I.e. when --iptables=true, the modification is done is wrong
(in a way that breaks networking configuration for non-docker software).
> On Tuesday, 27 November 2018 9:00:20 AM AEDT Marvin Renich wrote:
> > 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... :(
I appreciate your candor regarding upstream's attitude.
Would you mind forwarding this upstream anyway, to give them the
opportunity to do the right thing? Here is my suggestion to them to fix
this bug:
1. Only change the FORWARD chain policy if ip_forward was 0 before
adding rules to this chain (obviously docker sets ip_forward to 1 if
it wasn't already).
2. Only add two rules to FORWARD:
-A FORWARD -o docker0 -j DOCKER-IN
-A FORWARD -i docker0 -j DOCKER-OUT
Add all other rules to docker-specific chains (DOCKER-IN and -OUT can
jump to DOCKER-USER and -ISOLATION-* as desired). This ensures that
only docker-related packets make it to the docker chains, so the docker
chains cannot modify non-docker packets.
This has the advantage that you don't need to keep testing -i docker0 or
-o docker0 on multiple rules, making the filtering more efficient.
> 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.
Thanks for this tip; I'll investigate.
> > I'm raising this back to critical (makes unrelated software on the
> > system break),
>
> 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.
Okay. I understand and agree that the current situation is better than
not having docker in the archive. Since this has the potential to break
other software on initial installation or upgrade from an older version,
can you put an item in NEWS.Debian pointing to this bug and mentioning
the /etc/docker/daemon.json workaround?
Thanks for your work packaging docker!
...Marvin
