Podman v2 no longer allows clearing of entrypoint on the command line

[pzl]

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

/kind bug

Description

Previously, it was possible to override and erase the entrypoint of an image on the CLI. After the switch to cobra flag parsing, it seems that is no longer the case

Steps to reproduce the issue:

1. podman run --rm -it --entrypoint= alpine/git sh

Describe the results you received:

git: 'sh' is not a git command. See 'git --help'.

The most similar commands are
	show
	push

i.e. git sh was run

Describe the results you expected:

an sh prompt

Additional information you deem important (e.g. issue happens only occasionally):

the alpine/git image is small enough to reason with: source. It simply sets git as the entrypoint. I used to be able to erase the entrypoint entirely, and have sh be the command. Sure, I can work around this by setting sh as the entrypoint here, but for the general case, entrypoints cannot be erased anymore. Just overridden to a new value.

Here is the previous introduction of the feature: #585

Output of podman version:

Version:      2.0.1
API Version:  1
Go Version:   go1.14.4
Git Commit:   a11c4ead10177a66ef2810a0a92ea8ce2299da07
Built:        Sat Jun 27 16:04:26 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.0
  cgroupVersion: v2
  conmon:
    package: Unknown
    path: /usr/bin/conmon
    version: 'conmon version 2.0.18, commit: 7b3e303be8f1aea7e0d4a784c8e64a75c14756a4'
  cpus: 32
  distribution:
    distribution: arch
    version: unknown
  eventLogger: file
  hostname: architower
  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.7.7-arch1-1
  linkmode: dynamic
  memFree: 22871597056
  memTotal: 33644826624
  ociRuntime:
    name: crun
    package: Unknown
    path: /usr/bin/crun
    version: |-
      crun version 0.14
      commit: ebc56fc9bcce4b3208bb0079636c80545122bf58
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: Unknown
    version: |-
      slirp4netns version 1.1.2
      commit: 0806e04b1f786070cc1695d7f9b6abd43862bb5a
      libslirp: 4.3.0
      SLIRP_CONFIG_VERSION_MAX: 3
  swapFree: 0
  swapTotal: 0
  uptime: 4h 38m 8.01s (Approximately 0.17 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  configFile: /home/dan/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/dan/.config/data/containers/storage
  graphStatus: {}
  imageStore:
    number: 8
  runRoot: /run/user/1000/containers
  volumePath: /home/dan/.config/data/containers/storage/volumes
version:
  APIVersion: 1
  Built: 1593288266
  BuiltTime: Sat Jun 27 16:04:26 2020
  GitCommit: a11c4ead10177a66ef2810a0a92ea8ce2299da07
  GoVersion: go1.14.4
  OsArch: linux/amd64
  Version: 2.0.1

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

Name            : podman
Version         : 2.0.1-1
Description     : Tool and library for running OCI-based containers in pods
Architecture    : x86_64
URL             : https://github.com/containers/libpod
Licenses        : Apache
Groups          : None
Provides        : None
Depends On      : cni-plugins  conmon  device-mapper  iptables  libseccomp  runc  slirp4netns  libsystemd  fuse-overlayfs  skopeo
Optional Deps   : podman-docker: for Docker-compatible CLI
                  btrfs-progs: support btrfs backend devices [installed]
                  catatonit: --init flag support
                  crun: support for unified cgroupsv2 [installed]
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 89.15 MiB
Packager        : Morten Linderud <[email protected]>
Build Date      : Sat 27 Jun 2020 04:04:26 PM EDT
Install Date    : Sat 27 Jun 2020 09:42:52 PM EDT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

[skorhone]

It could be that I don't fully understand how pflags works... or it could be that parsing logic is flawed. All strings seem to default as empty when parsing. I don't see any way, how you would differentiate between an empty string set by user and a default value of empty.

Code that I looked at can be found here: podman/cmd/podman/common/create.go

For some reason entrypoint and few other bits are not parsed the same way that other variables using.

Considering that pflags provides neat interface for handling differences between set, empty and unset values, it might make sense to refactor code to make most of it.

My suggestion would be to have type ContainerCLIOpts store pflags as they are. Then provide named accessor functions to access values, so that you don't get magic variables all over the codebase. Accessor such as entrypoint could return ok, if there is actually a value defined

Should be trivial to fix and I could do it myself, if I wasn't on vacation 🙂

[skorhone]

Creating an interface for reading parameters would allow sharing code between API and cli. Interface could be used as one of input parameters to function that forms container spec: options + image + config -> spec -> container

[Luap99]

It could be that I don't fully understand how pflags works... or it could be that parsing logic is flawed. All strings seem to default as empty when parsing. I don't see any way, how you would differentiate between an empty string set by user and a default value of empty.

You can use something like: cmd.Flag("entrypoint").Changed. This will only be true if the flag is set on the command line.

[skorhone]

You could, but it would be a dirty hack. As is, code is really hard to follow. But as a quick fix, it should work.

Move to ContainerCLIOpts seems like a step towards having common structure and away from magic variables ("entrypoint" = magic var). It just needs another iteration with some love and care. And it desperately needs unit tests

[vincent-olivert-riera]

I'm also having this same issue. Before I was able to clear the entry point with --entrypoint="", but now it does not work any more.

$ podman version
Version:      2.0.2
API Version:  1
Go Version:   go1.14.3
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

That's the current version provided by Fedora 32, so this must be affecting many people.

[rhatdan]

As a work around this should work.

podman run --rm -it --entrypoint=sh alpine/git

[vincent-olivert-riera]

As a work around this should work.

podman run --rm -it --entrypoint=sh alpine/git

That's a workaround valid only for that particular case, because you want to run the sh command in that container.

I think that example was used just as a simple scenario to demonstrate the problem.

[rhatdan]

Yes, I was only suggesting it for your case. Hopefully My PR will get merged soon, and then we can back port it into podman-2.0.3

[vincent-olivert-riera]

@rhatdan that would be great :-) Thanks for taking care of this.

[vincent-olivert-riera]

@pzl , this has been fixed: #6939