Bug 1129622 - Docker daemon parameter --iptable=true leave mess in iptables after daemon finish
Summary: Docker daemon parameter --iptable=true leave mess in iptables after daemon fi...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1113141
TreeView+ depends on / blocked
 
Reported: 2014-08-13 11:21 UTC by Jiri Zupka
Modified: 2019-03-06 01:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-24 19:11:09 UTC


Attachments (Terms of Use)

Description Jiri Zupka 2014-08-13 11:21:54 UTC
Description of problem:
rhel with disabled firewalld.service.
Docker daemon with started with paramter --iptable=true --icc=false. Leaves in iptables some rules.

0        0 DROP       all  --  docker0 docker0  0.0.0.0/0   0.0.0.0/0           
0        0 ACCEPT     all  --  *      docker0  0.0.0.0/0   0.0.0.0/0  ctstate RELATED,ESTABLISHED
0        0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0  0.0.0.0/0

When docker is started again with with --iptables=false then it could
makes hidden problems with containers which are not able communicate. 



+ really minor think and minor problem in implementation in networkdriver/bridge/driver.go L:178 in got master branch with last commit  
       4398108433121ce2ac9942e607da20fa1680871a
Docker daemon iptables rules are different order after
  iptables -F
  docker -d --iptables=true --icc=true
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0  ctstate RELATED,ESTABLISHED
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0           
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0 
  docker -d --iptables=true --icc=false
    DROP       all  --  0.0.0.0/0  0.0.0.0/0           
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0  ctstate RELATED,ESTABLISHED
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0
  docker -d --iptables=true --icc=true
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0           
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0  ctstate RELATED,ESTABLISHED
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0

Version-Release number of selected component (if applicable):
docker-1.1.2-9.el7

How reproducible:
always


Steps to Reproduce:
1. systemctl stop firewalld.service
2. iptables -F (for sure)
3. systemctl stop docker.socket
4. systemctl stop docker.service
5. docker -d --iptables=true --icc=false
6. iptable -L  show some docker rules
7. terminate correctly docker daemon (ctrl-c)
8. iptables -L  show iptables rules which left there after docker daemon finish


Actual results:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


Expected results:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 


Additional info:

Comment 2 Daniel Walsh 2014-08-13 20:30:15 UTC
Not sure if cleaning up here is a good idea either.  Does docker know if it added the rules, so that it can remove them?  I would hate to have docker make firewall rules less strict when it exits

Comment 3 Jiri Zupka 2014-09-24 19:11:09 UTC
When docker will make containers standalone then it shouldn't be problem any more, moreover it will be needed behavior.

Standalone docker container -> when system kill docker daemon all docker 
                               containers stay alive


Note You need to log in before you can comment on or make changes to this bug.