Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

podman-remote defaults to client host's default network mode (slirp4netns when not running as root) #14368

Closed
LewisGaul opened this issue May 25, 2022 · 3 comments · Fixed by #14436
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. remote Problem is in podman-remote

Comments

@LewisGaul
Copy link

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

/kind bug

Description
podman-remote seems to be defaulting the HostConfig.NetworkMode value for containers based on whether the client side is root, rather than the remote.

Steps to reproduce the issue:

  1. Set up a podman-remote connection on a host running non-root to a remote host which will be connected to over ssh as root, e.g. CONTAINER_HOST='root@my-host/run/podman/podman.sock'
  2. Start a container, e.g. podman-remote run -it alpine
  3. Inspect the container's network mode, e.g. podman-remote inspect <ctr> | jq .[0].HostConfig.NetworkMode

Describe the results you received:

   > podman-remote inspect 6d | jq .[0].HostConfig.NetworkMode
"slirp4netns"

Describe the results you expected:
The same behaviour as running podman inside the remote host, i.e. use 'bridge' network mode by default:

   > podman-remote inspect 6d | jq .[0].HostConfig.NetworkMode
"bridge"

Output of podman version:

Client:
Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.16.8
Git Commit:   f6526ada1025c2e3f88745ba83b8b461ca659933
Built:        Wed Dec  8 13:15:01 2021
OS/Arch:      linux/amd64

Server:
Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.3
Built:        Wed Dec 31 16:00:00 1969
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 6
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: journald
  hostname: ubuntu
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.0-30-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 3193929728
  memTotal: 6222995456
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.6.1
  swapFree: 0
  swapTotal: 0
  uptime: 18h 15m 0.26s (Approximately 0.75 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 2
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.17.3
  OsArch: linux/amd64
  Version: 3.4.4

Package info (e.g. output of rpm -q podman or apt list podman):
On the remote host (podman-remote is a static binary that's been downloaded):

podman/jammy,now 3.4.4+ds1-1ubuntu1 amd64 [installed]

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
No (sorry)

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label May 25, 2022
@github-actions github-actions bot added the remote Problem is in podman-remote label May 25, 2022
@mheon
Copy link
Member

mheon commented May 26, 2022

I believe we fixed this in 4.1 - can you try 4.1.0?

@LewisGaul
Copy link
Author

I believe we fixed this in 4.1 - can you try 4.1.0?

I'm assuming the bug is in podman-remote, but I can't easily try out v4 because the Linux static binaries on the GH releases are actually Windows executables (there are open issues for this already).

@Luap99
Copy link
Member

Luap99 commented May 31, 2022

I don't think this is fixed. The problem is that the network option is passed on the client side into the spegcen format.
I will fix it.

@Luap99 Luap99 self-assigned this May 31, 2022
Luap99 added a commit to Luap99/libpod that referenced this issue Jun 1, 2022
When podman-remote is used we should not resolve the default network
mode on the client. Defaults should be set on the server. In this case
this is important because we have different defaults for root/rootless.
So when the client is rootless and the server is root we must pick the
root default.

Note that this already worked when --network was set since we did not
parsed the flag in this case. To reproduce you need --network=default.

Also removed a unused function.

[NO NEW TESTS NEEDED] I tested it manually but I am not sure how I can
hook a test like this up in CI. The client would need to run as rootless
and the server as root or the other way around.

Fixes containers#14368

Signed-off-by: Paul Holzinger <[email protected]>
mheon pushed a commit to mheon/libpod that referenced this issue Jun 14, 2022
When podman-remote is used we should not resolve the default network
mode on the client. Defaults should be set on the server. In this case
this is important because we have different defaults for root/rootless.
So when the client is rootless and the server is root we must pick the
root default.

Note that this already worked when --network was set since we did not
parsed the flag in this case. To reproduce you need --network=default.

Also removed a unused function.

[NO NEW TESTS NEEDED] I tested it manually but I am not sure how I can
hook a test like this up in CI. The client would need to run as rootless
and the server as root or the other way around.

Fixes containers#14368

Signed-off-by: Paul Holzinger <[email protected]>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. remote Problem is in podman-remote
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants