No error reported when pulling an image with the wrong architecture

[cfergeau]

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

/kind bug

Description

If I run podman pull --arch=bogus quay.io/centos/centos:centos7, podman will download an image:

$ podman pull --arch=bogus  quay.io/centos/centos:centos7
Trying to pull quay.io/centos/centos:centos7...
Getting image source signatures
Copying blob 2d473b07cdd5 done  
Copying config 8652b9f0cb done  
Writing manifest to image destination
Storing signatures
8652b9f0cb4c0599575e5a003f5906876e10c1ceb2ab9fe1786712dac14a50cf

but its architecture is not the expected one

$ podman inspect quay.io/centos/centos:centos7 |jq .[0].Architecture
"amd64"

If I raise the log-level to info, I at least a message about this: INFO[0001] Image operating system mismatch: image uses OS "linux"+architecture "amd64", expecting one of "linux+bogus"

Contrast this with multiarch images with a manifest:

$ podman pull --arch=bogus  quay.io/centos/centos:stream8
Trying to pull quay.io/centos/centos:stream8...
Error: choosing an image from manifest list docker://quay.io/centos/centos:stream8: no image found in manifest list for architecture bogus, variant "", OS linux

I'd expect the behaviour to be consistent in both cases, or to at least have an option to get an error in the former situation (I could not find one).

Output of podman version:

$ podman version
Client:       Podman Engine
Version:      4.1.0
API Version:  4.1.0
Go Version:   go1.18
Built:        Fri May  6 18:15:54 2022
OS/Arch:      linux/amd64

(this is on fedora36)

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.26.1
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.0-2.fc36.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpuUtilization:
    idlePercent: 90.76
    systemPercent: 2.21
    userPercent: 7.03
  cpus: 12
  distribution:
    distribution: fedora
    variant: workstation
    version: "36"
  eventLogger: journald
  hostname: chirashi.dolet.fergeau.eu
  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: 5.17.7-300.fc36.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 16050900992
  memTotal: 33380478976
  networkBackend: cni
  ociRuntime:
    name: crun
    package: crun-1.4.4-1.fc36.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.4.4
      commit: 6521fcc5806f20f6187eb933f9f45130c86da230
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    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,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
    version: |-
      slirp4netns version 1.2.0-beta.0
      commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 25354559488
  swapTotal: 25354559488
  uptime: 3h 30m 8.21s (Approximately 0.12 days)
plugins:
  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/teuf/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 0
    stopped: 3
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/teuf/.local/share/containers/storage
  graphRootAllocated: 410761109504
  graphRootUsed: 377703071744
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 9
  runRoot: /run/user/1000/containers
  volumePath: /home/

Package info (e.g. output of rpm -q podman or apt list podman):

podman-4.1.0-1.fc36.x86_64

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

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

This was tested on a physical laptop, but I think the behaviour would be reproducible regardless of the environment

[Luap99]

@vrothberg PTAL

[vrothberg]

Thanks for reaching out, @cfergeau!

This issue is an unfortunate and sad fact of life. Podman (and as matter of fact Docker as well) can only run a best effort approach when it comes to matching architectures (and OSes). For some short period of time, Podman threw an error when the requested platform did not match but that broke many users so it has been reverted with containers/image@976ae91.

The reason for the breakage is that many images in the wild specify a wrong platform. For a long period of time, even K8s images suffered from that issue. In some cases, it was a user error, in others some tools had bugs.

I am no fan of the current behavior but I do not see a way out. Docker does not error out either:
docker pull --platform linux/bogus quay.io/centos/centos:centos7

[cfergeau]

I understand there are backward-compatibility concerns involved, even if I did not realize some images were setting their arch wrong.
Could there be a command line flag/a config file option/... to make this check stricter while keeping the default behaviour? I can add some code to check the arch after the fact, but that feels like something podman should be helping with as its default behaviour is to not do what the user explicitly asked for, and with no indication whatsoever explaining what it did with the default log levels

[vrothberg]

Could there be a command line flag/a config file option/... to make this check stricter while keeping the default behaviour? I can add some code to check the arch after the fact, but that feels like something podman should be helping with as its default behaviour is to not do what the user explicitly asked for, and with no indication whatsoever explaining what it did with the default log levels

Definitely! I will add this requirement to #12682 which asks for the same check but when looking up images locally.