Newer versions of dockerd add the DOCKER-USER chain and modify the FORWARD chain of the system, even when specifying the --iptables=false command line option. This used to work in version 1.13.1.
severity 903635 critical thanks Justification: "makes unrelated software on the system (or the whole system) break" Installing docker.io changed my FORWARD chain policy to DROP, breaking networking for unrelated virsh-based VMs that I had installed on the machine at the time. This matches exactly the text for severity: serious.
Looks like a fix was proposed at: https://github.com/docker/libnetwork/pull/2339/files However this fix didn't receive any feedback from upstream so far, and I'm not familiar with the docker codebase myself. So I'm a bit reluctant to import this patch. And on the other hand, after a quick look the patch looks pretty straightforward and harmless. Maybe someone else wants to have a look at this patch and give some feedback? system) break" machine at
Actually this was fixed upstream lately, and the fix is in Debian testing already. See https://github.com/docker/libnetwork/pull/2339#issuecomment-487207550 There's still other iptables related bugs, the most outstanding being #903635. If this bug could be solved, then users could just run docker with `--iptables=false`. This is discussed upstream in the link above. In any case I will close this bug in the next changelog entry.
So, let's get back on the track: this very bug, #903635. As I mentioned above, there's a discussion with a work in progress to fix that upstream: https://github.com/docker/libnetwork/pull/2339 I don't think it will be ready in time for buster though. So I see two solutions going forward: - 1 Jonathan lower the severity of the bug so that it's not RC. - 2 I import the patch from github, even though it's work in progress. I will follow up and update the patch as soon as upstream release a proper fix, and it will be included in a point release of buster. If I don't get any feedback from you Jonathan in the following days, I'll go for solution number 2 then. Cheers
Hi, Arnaud On Fri, 10 May 2019 09:03:41 +0700 Arnaud Rebillout <arnaud.rebillout@collabora.com> wrote:> You hadn't Cc'd Jonathan (but I am, now) and I doubt that he's subscribed to this bug, so he probably never saw these messages. I'm just checking in here as a concerned maintainer of a reverse-dependency threatened with autoremoval. thanks and regards Afif
Hmm I'm a bit clumsy with the bugtracker, sorry, and thanks for following up :)
Hi Arnaud - sorry I missed your messages until now. I'd rather not do that, because I think RC is the right classification; *but* I don't feel necessarily (given the circumstances) that docker.io should be removed from Buster, so can I instead suggest we request that this bug is ignored for Buster? I think we need to ask the release team to do that (and tag accordingly) but I'll double-check the procedure. I bow to your judgement as maintainer as to whether the partial fix is worth applying on its own. Will the patch in #2339 address the specific issue of what happens on package install?
No problem :) The thing is, I don't know for sure. After reading all the conversation, it seems that it does fix the particular bug reported here. But upstream also points out that it's just a partial solution, that's why the patch is sitting there without anyone really merging it. It's not sure if an improved version of the patch will appear. The bug has been opened for a long time already (1.5 years), and upstream doesn't seem to care much. Myself, I don't have a test setup to reproduce the bug and then validate that the patch fixes it. And these days I can't afford the time to work on that. That's why I'm also reluctant to blindly import this patch (even though after looking at the diff itself, it looks rather trivial). Hence I think it would be safer to go for option 1 and request that the bug is ignored? Unless the reporter of the bug has the time and means to actually test the patch in #2339? For sure I will follow up on that during Buster lifecycle, hopefully upstream will fix this for real, and in any case I'll find the time at some point to properly test this patch. Regards, Arnaud
Hello, I don't understand... I thought the whole point of making a bug release-critical is to keep the bug out of the release (either by having it fixed or removing the package). It seems to me like the severity of this bug should just be lowered, but if you want to pursue a buster-ignore tag, someone please contact the release team and make it happen. https://www.debian.org/Bugs/Developer says explicit authorization is needed from the release managers, but I'd worry that an email to debian-release@lists.debian.org might get lost and it'd be weird to file a bug on release.debian.org asking to apply a tag to another bug. Again, I think it makes more sense to just lower the severity if you don't think it should affect the release. regards Afif
Hi Jonathan, DROP"? I set add `"iptables": false` to `/etc/docker/daemon.json`. Then reboot my laptop. Then run `iptables-save`. The result is ``` # Generated by xtables-save v1.8.2 on Mon Jun 10 01:22:35 2019 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :DOCKER-USER - [0:0] -A FORWARD -j DOCKER-USER -A DOCKER-USER -j RETURN COMMIT # Completed on Mon Jun 10 01:22:35 2019 ``` The FORWARD policy is ACCEPT. The origin bug is true that, docker still adds an empty chain, when iptables=false is set. But IMHO your justification is not real.
No, that's not the point; it's the consequence. There are clear criteria for the bug categories, "breaks unrelated software" is one of them and what is happening here. Someone should indeed do this. I might get around to it, but I can't promise, I'm very busy this week.
clone 903635 -1 retitle -1 installing and starting docker changes iptables FORWARD policy, breaking unrelated things severity 903635 important found 903635 18.09.1+dfsg1-7 found -1 18.09.1+dfsg1-7 thanks In a fresh test Buster installation. Before: After performed by the user, changes the FORWARD table policy, which breaks e.g. any running VMs on the host. Setting that does stop this from happening, yes. If this was the package default that would resolve the issue I have. But that would not address the original filer's issue (unnecessary chain DOCKER-USER creation, which I can reproduce). I should have filed a separate issue really, sorry. I've cloned now.