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.

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

Environment passing behavior differes from docker #3648

Closed
JoshuaWatt opened this issue Jul 26, 2019 · 4 comments · Fixed by #3665
Closed

Environment passing behavior differes from docker #3648

JoshuaWatt opened this issue Jul 26, 2019 · 4 comments · Fixed by #3665
Assignees
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

@JoshuaWatt
Copy link

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

/kind bug

Description

Passing environment variables using the form -e VAR (without assigning a value) differs from the docker behaviour. In docker, the variable will only be passed if set in the parent shell, where as podman always passes the variable, assigning it an empty value if not present in the parent shell.

Steps to reproduce the issue:

  1. Pass an unset environment variable by name only (e.g. -e VAR) and notice that is set in the parent container

Describe the results you received:
A variable that is not set in the parent shell is present in the containers environment:

$ unset NOT_SET
$ podman run --rm -it -e NOT_SET ubuntu:bionic
root@3d8f6395cb15:/# echo ${NOT_SET+isset}
isset
root@3d8f6395cb15:/# exit
exit

Describe the results you expected:
The variable should not be set in the container if not set in the parent shell:
Example from docker:

$ unset NOT_SET
$ docker run --rm -it -e NOT_SET ubuntu:bionic
root@fdcd023502f0:/# echo ${NOT_SET+isset}

root@fdcd023502f0:/# exit
exit

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

Output of podman version:

Version:            1.4.4
RemoteAPI Version:  1
Go Version:         go1.12.7
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.7
  podman version: 1.4.4
host:
  BuildahVersion: 1.9.0
  Conmon:
    package: podman-1.4.4-4.fc30.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.0.0-dev, commit: 164df8af4e62dc759c312eab4b97ea9fb6b5f1fc'
  Distribution:
    distribution: fedora
    version: "30"
  MemFree: 1684598784
  MemTotal: 16769097728
  OCIRuntime:
    package: containerd.io-1.2.6-3.3.fc30.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc8
      commit: 425e105d5a03fabd737a126ad93d62a9eeede87f
      spec: 1.0.1-dev
  SwapFree: 132059795456
  SwapTotal: 137438949376
  arch: amd64
  cpus: 8
  hostname: ola-842mrw1
  kernel: 5.1.15-300.fc30.x86_64
  os: linux
  rootless: true
  uptime: 546h 39m 49.25s (Approximately 22.75 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/wattj/.config/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/wattj/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 28
  RunRoot: /run/user/9542
  VolumePath: /home/wattj/.local/share/containers/storage/volumes

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

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Jul 26, 2019
@baude
Copy link
Member

baude commented Jul 26, 2019

@jwhonce can you please take a look at this one?

@rhatdan
Copy link
Member

rhatdan commented Jul 29, 2019

@JoshuaWatt Do you have a script/container that relies on this? BTW I am fine with the Docker version, or throwing an error, or the podman version. But if Docker works this way it is probably best that we mimic it.

@JoshuaWatt
Copy link
Author

@rhatdan I've been working on adding podman support to our containerized build system (https://github.com/garmin/pyrex) that was previously Docker-only. Podman is appealing because it plugs one of the major security holes in the system. For the most part, podman has been a drop in replacement (which is nice). We can work around this issue because we have control over how podman/docker is invoked, so we can manually check if the environment variable is set before passing it as an argument, but it would be nice if we didn't have to do that and they behaved the same.

@rhatdan
Copy link
Member

rhatdan commented Jul 29, 2019

@QiWang19 PTAL

QiWang19 added a commit to QiWang19/podman that referenced this issue Jul 30, 2019
close containers#3648

podman create and podman run do not set --env variable if the environment is not present with a value

Signed-off-by: Qi Wang <[email protected]>
@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 Sep 24, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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
Development

Successfully merging a pull request may close this issue.

6 participants