podman pull does not work

[Karotte128]

Issue Description

podman pull results in Error: initializing source docker://libary/ubuntu:latest: pinging container registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 192.168.178.1:53: dial udp 192.168.178.1:53: socket: permission denied

Steps to reproduce the issue

Steps to reproduce the issue

1. podman pull ubuntu:latest

Describe the results you received

Error: initializing source docker://libary/ubuntu:latest: pinging container registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 192.168.178.1:53: dial udp 192.168.178.1:53: socket: permission denied

Describe the results you expected

podman should pull the container image

podman info output

host:
  arch: amd64
  buildahVersion: 1.28.2
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon_2.1.6+ds1-1_amd64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.6, commit: unknown'
  cpuUtilization:
    idlePercent: 98.95
    systemPercent: 0.52
    userPercent: 0.53
  cpus: 2
  distribution:
    codename: mantic
    distribution: ubuntu
    version: "23.10"
  eventLogger: journald
  hostname: CT109
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.8.4-2-pve
  linkmode: dynamic
  logDriver: journald
  memFree: 1639899136
  memTotal: 2147483648
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun_1.8.5-1_amd64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.5
      commit: b6f80f766c9a89eb7b1440c0a70ab287434b17ed
      rundir: /run/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_AUDIT_WRITE,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_MKNOD,CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns_1.2.0-1_amd64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 0
  swapTotal: 0
  uptime: 0h 31m 5.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 8350298112
  graphRootUsed: 1269452800
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.21.1
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

Podman in a container

Yes

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

podman is running in proxmox lxc container

Additional information

this worked until now, after a reboot it was broken

[Luap99]

socket: permission denied

This is not a podman problem, your LXC or whatever likely blocks networking.

[Aster-the-Med-Stu]

Could confirm it's network issue. Nowadays Proxmox has apparmor, and the default config blocks podman network!

Taken from my dmesg:

[25690.731206] audit: type=1400 audit(1728949935.450:1904): apparmor="DENIED" operation="create" class="net" namespace="root//lxc-1002_<-var-lib-lxc>" profile="podman" pid=132774 comm="pasta.avx2" family="inet" sock_type="stream" protocol=6 requested="create" denied="create"

You might wish to run systemctl stop apparmor on your PVE host before editing apparmor audit.

[LoganTann]

Thanks a lot for hinting about apparmor. I spent a whole hour trying to debug why I couldn't pull images...

[sbrivio-rh]

But wait, pasta ships its own AppArmor profile (https://passt.top/passt/tree/contrib/apparmor), and now it should finally run with it as the AppArmor stub for Podman was dropped (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100135). Is this Debian? Ubuntu?

Don't just whack AppArmor please, report issues (with excerpts from audit.log) if you find them!

[LoganTann]

In my case, Podman was installed in an Ubuntu LXC container, which itself was running on Proxmox VE. The AppArmor on the Proxmox host was blocking my container from accessing the network configuration.

In any case, trying to install Podman inside an LXC container is a very bad idea, I should just have used a true VM; I never managed to get it working (which makes perfect sense), so I gave up.

[sbrivio-rh]

So I suppose it's Debian, but perhaps without https://salsa.debian.org/apparmor-team/apparmor/-/commit/afd2a9ade8bd32f050b8ebe3d4221730db75c2ab? If that's the case, then it's all fine. I'm just trying to make sure that it's not an issue we still have either in the upstream AppArmor profile for pasta or in the Debian package (I maintain both).