podman-remote on windows doesn't send environment variables passed with --env to remote

[SpiralP]

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

/kind bug

Description

podman-remote on windows doesn't send environment variables passed with --env to the remote.

Steps to reproduce the issue:

1. Download podman-remote-release-windows.zip from GitHub release v3.4.1 and unzip
2. Open cmd in unzipped folder
3. Add remote connection via ssh:

.\podman.exe system connection add remote --default --identity C:\Users\User\.ssh\id_rsa ssh://user@remote/tmp/podman-run-1000/podman/podman.sock

2. Execute a remote podman run command with an environment variable passed with --env:

.\podman.exe --remote run --rm --env NEW_ENV_VAR=some-value alpine env

3. Look at output (and notice it's missing our NEW_ENV_VAR):

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm
container=podman
HOME=/root
HOSTNAME=88c4f25159c2

Describe the results you expected:

Expecting NEW_ENV_VAR to be passed to remote, and shown in container's env output.
On linux or mac it looks like:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm
container=podman
NEW_ENV_VAR=some-value
HOME=/root
HOSTNAME=19e4b20e6f86

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

• This doesn't happen on linux or mac, where -e is passed correctly to the remote.
• Using --env-file .env on windows works fine to pass vars from .env file.

Although I'm less interested in this being solved, the "read host's current env var" mode also doesn't work:
linux:

localhost:~# export ASDF=value
localhost:~# podman --remote run --rm -e ASDF alpine env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm
container=podman
ASDF=value
HOME=/root
HOSTNAME=bc5513ad8573

windows:

C:\Users\User\Desktop\podman-3.4.1>set ASDF=value
C:\Users\User\Desktop\podman-3.4.1>.\podman.exe --remote run --rm -e ASDF alpine env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm
container=podman
HOME=/root
HOSTNAME=2c87365b896c

Output of podman version:

Client:
Version:      3.4.1
API Version:  3.4.1
Go Version:   go1.15.15
Git Commit:   a6493ae6904a5b7dde2395a374cb77fc45c8a3bc
Built:        Wed Oct 20 07:22:45 2021
OS/Arch:      windows/amd64

Server:
Version:      3.4.1
API Version:  3.4.1
Go Version:   go1.17.2
Git Commit:   aec2d30e2279bdf6db29063df8b1455fb44dc49e
Built:        Wed Oct 20 09:44:46 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: Unknown
    path: /usr/bin/conmon
    version: 'conmon version 2.0.30, commit: 4ab06de98f48513b22602d23d59d63b29e75824b'
  cpus: 1
  distribution:
    distribution: alpine
    version: 3.15.0_alpha20210804
  eventLogger: file
  hostname: ovh
  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.10.74-0-lts
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 1422688256
  memTotal: 2034712576
  ociRuntime:
    name: crun
    package: Unknown
    path: /usr/bin/crun
    version: |-
      crun version 1.2
      commit: 4f6c8e0583c679bfee6a899c05ac6b916022561b
      spec: 1.0.0
      +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /tmp/podman-run-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: /etc/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: Unknown
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 2147479552
  swapTotal: 2147479552
  uptime: 42m 54.18s
plugins:
  log:
  - k8s-file
  - none
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: Unknown
      Version: |-
        fuse-overlayfs: version 1.7.1
        fusermount3 version: 3.10.5
        FUSE library version 3.10.5
        using FUSE kernel interface version 7.31
  graphRoot: /home/user/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 43
  runRoot: /tmp/podman-run-1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.1
  Built: 1634748286
  BuiltTime: Wed Oct 20 16:44:46 2021
  GitCommit: aec2d30e2279bdf6db29063df8b1455fb44dc49e
  GoVersion: go1.17.2
  OsArch: linux/amd64
  Version: 3.4.1

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

My remote is using podman-3.4.1-r0 from alpine's edge repo, windows version is 3.4.1 from the GitHub release.

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, no mention of environment variables at all.

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

I ran into this bug after trying to use podman-compose, which passes docker-compose.yml's environment: vars to a podman create command with -e. The bug also happens in podman v3.4.0.

Thanks!

[vrothberg]

Thanks for opening the issue, @SpiralP. That's a curious one!

@jwhonce, any ideas what's going on? Looking at the code, I am clueless and I do not have any Windows machine for testing.

[SpiralP]

you can get free windows vm's here https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ but it might be a little bit of work to set up.

I'll also try reproducing on the win10 vm tomorrow if I remember!

[SpiralP]

I can confirm that the bug also exists in a fresh windows 10 vm from the above link

[rhatdan]

@baude PTAL

[github-actions]

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

[rhatdan]

@ashley-cui Do you have access to a Windows box to see what is going on here?

[n1hility]

@rhatdan Ran into this one as well. The windows env parsing is stubbed out via an "unsupported" impl using build tag atm. I was planning to fix as a followup of #12503 but if @ashley-cui you want to take that one thats great too!

[ashley-cui]

Unfortunately I don't have a windows box ATM, so feel free to grab this one @n1hility

[thangchung]

I tried to run podman on Windows 11 with tye (just like docker-compose, and podman underline).

I have passed .env file as

 - name: databaseserver
    image: postgres:11-alpine
    env_file:
      - .env
    bindings:
      - name: "5432"
        port: 5432
        connectionString: Server=${host};Port=${port};User Id=${env:POSTGRES_USER};Password=${env:POSTGRES_PASSWORD};
    volumes:
      - name: postgres-storage
        target: /var/lib/postgresql/data

Inside .env file:

POSTGRES_PASSWORD=P@ssw0rd
POSTGRES_USER=lab

The logs are as follows

databaseserver postgres:11-alpine
[databaseserver_cf8b5873-f]: 87332fb68565addb4ca547992cf2fe3e6c416634f4a3e99477d9f6291b824fa0
[databaseserver_cf8b5873-f]: Error: Database is uninitialized and superuser password is not specified.
[databaseserver_cf8b5873-f]: You must specify POSTGRES_PASSWORD to a non-empty value for the
[databaseserver_cf8b5873-f]: superuser. For example, "-e POSTGRES_PASSWORD=password" on "docker run".
[databaseserver_cf8b5873-f]:
[databaseserver_cf8b5873-f]: You may also use "POSTGRES_HOST_AUTH_METHOD=trust" to allow all
[databaseserver_cf8b5873-f]: connections without a password. This is *not* recommended.
[databaseserver_cf8b5873-f]:
[databaseserver_cf8b5873-f]: See PostgreSQL documentation about "trust":
[databaseserver_cf8b5873-f]: https://www.postgresql.org/docs/current/auth-trust.html
[databaseserver_cf8b5873-f]: Error: Database is uninitialized and superuser password is not specified.
[databaseserver_cf8b5873-f]: You must specify POSTGRES_PASSWORD to a non-empty value for the
[databaseserver_cf8b5873-f]: superuser. For example, "-e POSTGRES_PASSWORD=password" on "docker run".
[databaseserver_cf8b5873-f]:
[databaseserver_cf8b5873-f]: You may also use "POSTGRES_HOST_AUTH_METHOD=trust" to allow all
[databaseserver_cf8b5873-f]: connections without a password. This is *not* recommended.
[databaseserver_cf8b5873-f]:
[databaseserver_cf8b5873-f]: See PostgreSQL documentation about "trust":
[databaseserver_cf8b5873-f]: https://www.postgresql.org/docs/current/auth-trust.html
[databaseserver_cf8b5873-f]: Error: Database is uninitialized and superuser password is not specified.
[databaseserver_cf8b5873-f]: You must specify POSTGRES_PASSWORD to a non-empty value for the
[databaseserver_cf8b5873-f]: superuser. For example, "-e POSTGRES_PASSWORD=password" on "docker run".
[databaseserver_cf8b5873-f]:
[databaseserver_cf8b5873-f]: You may also use "POSTGRES_HOST_AUTH_METHOD=trust" to allow all
[databaseserver_cf8b5873-f]: connections without a password. This is *not* recommended.
[databaseserver_cf8b5873-f]:
[databaseserver_cf8b5873-f]: See PostgreSQL documentation about "trust":
[databaseserver_cf8b5873-f]: https://www.postgresql.org/docs/current/auth-trust.html

That mean podman couldn't pass any env variables into it container, I guessed :(