Flag --dns does not set /etc/resolv.conf when using another containers network

[space88man]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

I am creating a container with --dns <MYDNS1> -- dns <MYDNS2> --network container:another.

/etc/resolv.conf is written with 1.1.1.1 and 1.0.0.1, instead of the expected <MYDNS1>, <MYDNS2>

Steps to reproduce the issue:

podman run -d --rm --name sharp_sutherland pause
podman run --rm -a stdin,stdout,stderr -it --entrypoint /bin/bash --dns 192.168.15.1 --name jovial_brown  --network container:sharp_sutherland centos:7

podman exec jovial_brown cat /etc/resolv.conf
nameserver 192.168.20.1
# ^^^^ this is the nameserver used by the host
# not intended for the container

Describe the results you received:
The dependent container uses the nameserver of the host.

Describe the results you expected:
The dependent container uses the nameserver specified with --dns X.X.X.X

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Version:            1.4.5-dev
RemoteAPI Version:  1
Go Version:         go1.12.6
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:         
  compiler: gc                  
  git commit: ""                                                                                
  go version: go1.12.6
  podman version: 1.4.5-dev
host:         
  BuildahVersion: 1.9.0
  Conmon: 
    package: podman-1.4.4-1.fc30.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 0.2.0, commit: 41010e63c287618b1dc34ee11d10d268e2feeefe'
  Distribution:  
    distribution: fedora                                                                        
    version: "30"
  MemFree: 39088803840
  MemTotal: 67458465792
  OCIRuntime:
    package: runc-1.0.0-93.dev.gitb9b6cc6.fc30.x86_64
    path: /usr/bin/runc       
    version: |-
      runc version 1.0.0-rc8+dev
      commit: e3b4c1108f7d1bf0d09ab612ea09927d9b59b4e3
      spec: 1.0.1-dev
  SwapFree: 0                             
  SwapTotal: 0   
  arch: amd64 
  cpus: 16                
  hostname: podman.localhost
  kernel: 5.1.16-300.fc30.x86_64      
  os: linux                             
  rootless: false
  uptime: 23h 46m 46.69s (Approximately 0.96 days)
registries:                     
  blocked: null            
  insecure: null          
  search:    
  - docker.io 
  - registry.fedoraproject.org        
  - quay.io                                                                                     
  - registry.access.redhat.com
  - registry.centos.org  
store:               
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 22
  GraphDriverName: overlay
  GraphOptions:             
  - overlay.mountopt=nodev,metacopy=on
  GraphRoot: /var/lib/containers/storage
  GraphStatus:   
    Backing Filesystem: btrfs                                                                   
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  ImageStore:
    number: 26
  RunRoot: /var/run/containers/storage
  VolumePath: /var/lib/containers/storage/volumes   

Additional environment details (AWS, VirtualBox, physical, etc.):

[mheon]

I'm assuming you're running rootless?

[mheon]

Ahhh - I think I know what we might be seeing here.

--network container: forces the use of the other container's resolv.conf, and AFAIK overrides --dns (this should probably generate a warning or error, though - it's not really clear if that's actually what happened, hence this bug).

I'd make some changes to resolv.conf in one container and see if they're reflected in the other container. That would be a surefire way to tell.

[space88man]

The following scenarios are as root:

Original test: leading pause container has no usable network/DNS; command line --dns is ignored for dependent container and 1.1.1.1 and 1.0.0.1 are injected.

If I create the pause container with a working /etc/resolv.conf; the command line --dns is ignored and the DNS from the leading container is injected.

Is this the intended behaviour?

[mheon]

This sounds intended, though the way we're handling --dns for the second container is definitely not correct. We either need to refuse to create the container on the grounds that --dns and --net=container: are incompatible, or we need to respect the DNS flag for --net=container:.

[space88man]

If the behaviour for --dns for network-dependent containers is not yet cast in stone, I vote for the latter 😄!

[rhatdan]

What does Docker do?

[rhatdan]

What do we do with Pods?

[space88man]

Docker follows @mheon first option:

# docker run -a stdin -a stdout -a stderr --tty -i  --name test_2  --network container:test_1 --dns 192.168.12.4 centos:7 /bin/bash
/usr/bin/docker-current: Error response from daemon: Conflicting options: dns and the network mode.
See '/usr/bin/docker-current run --help'

[rhatdan]

@QiWang19 Could you make all of the --dns commands conflict with --net = container:* calls.