/containers/create?name={name} cannot create container with Ulimits

[baatl]

Issue Description

As previously filed in issue #9803 (Finding 4), which was prematurely closed after only Finding 1 (Volumes can not be created without a name) was resolved.

This impacts other downstream issues, such as containrrr/watchtower#1060.

This issue impacts the version of Podman that currently ships with the latest LTS release of Ubuntu (22.04): if this is fixed in a newer release, it would be useful for that fix to be backported (currently, the simplest fix for our use case was to abandon Podman altogether).

Steps to reproduce the issue

The API endpoint /containers/create?name= offers a wide range of settings for the new container. In the HostConfig there is the subitem Ulimits which is a list of limits. If this subitem is present, the construction of the new container stops.

payload.json

...
"HostConfig": {...
"Ulimits": [
      {
        "Hard": 1048576,
        "Name": "RLIMIT_NOFILE",
        "Soft": 1048576
      },
      {
        "Hard": 4194304,
        "Name": "RLIMIT_NPROC",
        "Soft": 4194304
      }
    ],
    ...
}

Describe the results you received

sudo curl --unix-socket /run/podman/podman.sock -H "Content-Type: application/json" --data-binary "@payload.json" -X POST "http://d/v1.0.0/containers/create?name=my_new_container"

With Ulimits in the HostConfig:

{
  "cause": "invalid ulimit type: RLIMIT_NOFILE",
  "message": "fill out specgen: ulimit option \"RLIMIT_NOFILE=1048576:1048576\" requires name=SOFT:HARD, failed to be parsed: invalid ulimit type: RLIMIT_NOFILE",
  "response": 500
}

If one deletes the Ulimits block from the payload the /create call returns:

{
  "Id": "c80819be480f226871996d6f6b961ebd8fafbb2bbabeacec42f769008f3882b2",
  "Warnings": []
}

Describe the results you expected

A test of the Docker API with Ulimits in the HostConfig shows that the Docker API can create a new container with Ulimits.

curl --unix-socket /var/run/docker.sock -H "Content-Type: application/json" --data-binary "@/home/jbartscher/payload_docker.json" -X POST "http://localhost/v1.40/containers/create?name=my_new_container_from_docker"

{
  "Id": "1ff016427b223594a187294b6e282dd6baad5ca3ffad17b479ea93774aff61a6",
  "Warnings": []
}

podman info output

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: 2
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: journald
  hostname: mommy
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.0-101-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 1051357184
  memTotal: 2008821760
  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: true
    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: false
  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: 29m 52.14s
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 5
    paused: 0
    running: 4
    stopped: 1
  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: 5
  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.18.1
  OsArch: linux/amd64
  Version: 3.4.4

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

No

Additional environment details

No response

Additional information

No response

[rhatdan]

Can you confirm if this is fixed in podman 5.0? We do not back port fixes to every distribution and hardly back port fixes to any distribution. (Red Hat employees do sometimes back port fixes to older RHEL versions, but even here we try to roll forward fairly agressively.) RHEL 9.4 will have podman 4.9 and RHEL 9.5 will have podman 5.*.

Ubuntu would have to rely on community people to backport fixes or update versions for use with Ubuntu.

[baatl]

I can try it on Fedora 39 with Podman 4.9.

[Luap99]

Duplicate of #18077

Was fixed in #18078 (podman v4.5)