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.

Sign up for GitHub

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

Jump to bottom

network mode container fails if container use host mode #18027

Closed
Codelax opened this issue Apr 3, 2023 · 1 comment · Fixed by #18344
Closed

network mode container fails if container use host mode #18027

Codelax opened this issue Apr 3, 2023 · 1 comment · Fixed by #18344
Assignees
@Luap99
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.

Comments

@Codelax
Copy link

Codelax commented Apr 3, 2023

Issue Description

Starting a container with network="container:" will fails if target container use host mode.

Steps to reproduce the issue

Steps to reproduce the issue

  1. podman run -d --network=host alpine tail -f /dev/null
  2. podman run --network="container:<previous-sha>" alpine

Describe the results you received

Error: crun: cannot setns `/proc/945085/ns/net`: Operation not permitted: OCI permission denied

Describe the results you expected

I expected my new container to be created using the same network: host

podman info output

host:
  arch: amd64
  buildahVersion: 1.29.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.7-2.fc37.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: '
  cpuUtilization:
    idlePercent: 71.54
    systemPercent: 6.5
    userPercent: 21.95
  cpus: 16
  distribution:
    distribution: fedora
    variant: workstation
    version: "37"
  eventLogger: journald
  hostname: fedora
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.1.18-200.fc37.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 2463318016
  memTotal: 15936348160
  networkBackend: cni
  ociRuntime:
    name: crun
    package: crun-1.8.1-1.fc37.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.1
      commit: f8a096be060b22ccd3d5f3ebe44108517fbf6c30
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/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
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-8.fc37.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 4868632576
  swapTotal: 8589930496
  uptime: 336h 27m 29.00s (Approximately 14.00 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/me/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 1
    stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/me/.local/share/containers/storage
  graphRootAllocated: 510389125120
  graphRootUsed: 101789437952
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 436
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/me/.local/share/containers/storage/volumes
version:
  APIVersion: 4.4.2
  Built: 1677669779
  BuiltTime: Wed Mar  1 12:22:59 2023
  GitCommit: ""
  GoVersion: go1.19.6
  Os: linux
  OsArch: linux/amd64
  Version: 4.4.2

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

No response

Additional information

I tried the same using docker in a clean environment, it works correctly in root and rootless.

Found for nektos/act#303
@Codelax Codelax added the kind/bug Categorizes issue or PR as related to a bug. label Apr 3, 2023
@Luap99
Copy link
Member

Luap99 commented Apr 3, 2023

I think I fixed that for pods before, the problem is that we are not allowed to the a setns to the host namspace. However we are still in the host ns so the correct thing for podman is to translate container:xxx to host if the target container runs with --net=host, in this case the setns will be skipped.

@Luap99 Luap99 self-assigned this Apr 24, 2023
Luap99 added a commit to Luap99/libpod that referenced this issue Apr 25, 2023
@Luap99
rootless: support joining contianers that use host ns
d222a39 
The problem right now is that --ns contianer: syntax causes use to add
the namespace path to the spec which means the runtime will try to call
setns on that. This works fine for private namespaces but when the host
namspace is used by the container a rootless user is not allowed to
join that namespace so the setns call will return with permission
denied.

The fix is to effectively switch the container to the `host` mode
instead of `container:` when the mention container used the host ns. I
tried to fix this deep into the libpod call when we assign these
namespaces but the problem is that this does not work correctly because
these namespace require much more setup. Mainly different kind of mount
points to work correctly.

We already have similar work-arounds in place for pods because they also
need this.

For some reason this does not work with the user namespace, I don't know
why and I don't think it is really needed so I left this out just to get
at least the rest working. The original issue only reported this for the
network namespace.

Fixes containers#18027

Signed-off-by: Paul Holzinger <[email protected]>
@Luap99 Luap99 mentioned this issue Apr 25, 2023
Merged
@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 Aug 26, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@Luap99 Luap99

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.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

rootless: support joining containers that use host ns Luap99/libpod
2 participants
@Codelax @Luap99