Unable to skip default environment variables

[mr-c]

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

/kind bug

Description

I expect podman run to inject the same environment variables as docker run does; and if not to have a way to override that

Steps to reproduce the issue:

1. Compare the results of /usr/bin/docker run debian env to /usr/bin/podman run debian env

2. See the extra container and TERM environment variables.

3. There is no way to unset these extra environment variables, as the command-line syntax only allows for setting to an empty string

Describe the results you received:

$ /usr/bin/docker run debian env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=4019e3513006
HOME=/root

$ podman run debian env 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm
container=podman
HOME=/root
HOSTNAME=b30982541f3a

$ podman run --env "TERM=" --env "container=" debian env 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=
container=
HOME=/root
HOSTNAME=14eb11cf0356

Describe the results you expected:

The behaviour of /usr/bin/podman run would match /usr/bin/docker run as promised in https://docs.podman.io/en/latest/markdown/podman.1.html

Output of podman version:

michael@mrc-tux:~/cwltool$ podman version
Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.16.7
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.22.3
  cgroupControllers: []
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 8
  distribution:
    distribution: debian
    version: unknown
  eventLogger: journald
  hostname: mrc-tux
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
  kernel: 5.10.0-8-amd64
  linkmode: dynamic
  memFree: 4588969984
  memTotal: 67142504448
  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:
    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: 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: 213h 29m 20.82s (Approximately 8.88 days)
registries: {}
store:
  configFile: /home/michael/.config/containers/storage.conf
  containerStore:
    number: 11
    paused: 0
    running: 0
    stopped: 11
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
      Version: |-
        fusermount3 version: 3.10.4
        fuse-overlayfs: version 1.7.1
        FUSE library version 3.10.4
        using FUSE kernel interface version 7.31
  graphRoot: /home/michael/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 11
  runRoot: /run/user/1000/containers
  volumePath: /home/michael/.local/share/containers/storage/volumes
version:
  APIVersion: 3.3.1
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.16.7
  OsArch: linux/amd64
  Version: 3.3.1

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

Listing... Done
podman/testing,now 3.3.1+ds2-1 amd64 [installed]
podman/testing 3.3.1+ds2-1 i386

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes and yes, respectively

[mr-c]

Context, we are looking at formally supporting podman in the reference implementation of the Common Workflow Language standards: common-workflow-language/cwltool#1516 (review)

For CWL we are interested in strict reproducibility, so controlling the execution environment is important to us

[rhatdan]

Most likely you would want --unsetenv TERM --unsetenv container?

[rhatdan]

Or we could add something to containers.conf for default environment variables.

[mr-c]

Thanks for the quick response!

Most likely you would want --unsetenv TERM --unsetenv container?

That could work. Though many users alias docker=podman so it would be hard to know when to add those without breaking docker users.

Or we could add something to containers.conf for default environment variables.

Preferably something we can set from the command line or an environment variable (like PODMAN_NO_DEFAULT_ENV, so we don't force users to change their local configuration.

[mheon]

I don't think this is consistent even between Docker versions. I ran the same command on Docker 19.03, for example, and it did in fact include TERM=xterm. I know that container=podman is unique to us, but the rest is dependent on the exact version of the OCI spec generator in use and what default environment variables are set in there.

[mr-c]

I don't think this is consistent even between Docker versions. I ran the same command on Docker 19.03, for example, and it did in fact include TERM=xterm. I know that container=podman is unique to us, but the rest is dependent on the exact version of the OCI spec generator in use and what default environment variables are set in there.

Thanks for testing. To me, this makes it even more important to be able to remove "default" environment variables.

[rhatdan]

I think the best we could do is define them within the containers.conf and then allow admins to specify which ones they want.

[mr-c]

@rhatdan If a program sets CONTAINERS_CONF pointing to a valid containers.conf that contains only the environment variable overrides you propose, will that blend with the other user and site configuration choices, or will it override all of them?

[rhatdan]

It will only use merge the built in defaults and the containers.conf.
If you want to hack it so it will use /usr and /etc versions, you could set the $HOME directory. And put the file in
$HOME/.config/containers/containers.conf

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[mr-c]

Thanks, this the environment variable overrides suggested still need implementing

[flouthoc]

@mr-c Following is a duplicate of #11836. Closing this one so we could track implementation at a common place. Please feel free to re-open.