[Windows] White spaces in environment variables' names prevent containers from starting

[dvdjv]

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

/kind bug

Description

podman run errors out if there is a host environment variable defined with a white space in its name.

Steps to reproduce the issue:

1. Install IntelliJ Idea

2. Try running a container

Describe the results you received:

PS C:\Users\David> podman run --rm -ti alpine
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob sha256:530afca65e2ea04227630ae746e0c85b2bd1a179379cbf2b6501b49c4cab2ccc
Copying config sha256:d7d3d98c851ff3a95dbcb70ce09d186c9aaf7e25d48d55c0f99aae360aecfd53
Writing manifest to image destination
Storing signatures
Error: error parsing host environment variables: name "IntelliJ IDEA" has white spaces, poorly formatted name

Describe the results you expected:

Although personally I wouldn't use white spaces in my environment variables' names, apparently it is a valid scenario in Windows. Such variables should not prevent podman from starting containers.

Output of podman version:

PS C:\Users\David> podman version
Client:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.16.15
Git Commit:   f73d8f8875c2be7cd2049094c29aff90b1150241
Built:        Wed Jun 15 14:17:12 2022
OS/Arch:      windows/amd64

Server:       Podman Engine
Version:      4.2.0-rc3
API Version:  4.2.0-rc3
Go Version:   go1.16.15
Built:        Fri Aug  5 21:18:20 2022
OS/Arch:      linux/amd64

Output of podman info:

PS C:\Users\David> podman info
host:
  arch: amd64
  buildahVersion: 1.27.0-dev
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.3-1.fc35.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.3, commit: '
  cpuUtilization:
    idlePercent: 99.96
    systemPercent: 0.02
    userPercent: 0.03
  cpus: 16
  distribution:
    distribution: fedora
    variant: container
    version: "35"
  eventLogger: file
  hostname: caracal
  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.102.1-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 14452342784
  memTotal: 16568848384
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.5-1.fc35.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.5
      commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    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: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc35.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 4294430720
  swapTotal: 4294967296
  uptime: 46h 9m 51.00s (Approximately 1.92 days)
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/user/.local/share/containers/storage
  graphRootAllocated: 269490393088
  graphRootUsed: 1139048448
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 2
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 4.2.0-rc3
  Built: 1659730700
  BuiltTime: Fri Aug  5 21:18:20 2022
  GitCommit: ""
  GoVersion: go1.16.15
  Os: linux
  OsArch: linux/amd64
  Version: 4.2.0-rc3

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

Yes

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

A physical Windows box with IntelliJ Idea installed.

[baude]

hi @javakhishvili thanks for the report ... it seems odd that the existence of just having an application installed would break things ... you are not even running the container with intelli j ... does the application inject environment variables for all sessions?

[dvdjv]

It indeed does. IntelliJ Idea adds the variable to the user's profile. Fun fact: running a container from within IntelliJ works just fine. Perhaps, it uses the API calls directly.

[mheon]

@n1hility PTAL

[baude]

@mheon @n1hility please note I have assigned this to myself ... and i'm working on it.

[n1hility]

@baude cool thanks

[baude]

Ok, investigated this. I clean installed windows and then intelli idea. When running a container, I did not observe any failure. I also could not find any variable related to intellij.

Is it possible you might be using an older version by chance? In Linux, environment variable 'keys' are not allowed to have spaces by definition. Perhaps windows does allow this, but when interacting with Podman machine (which is Linux), this will most certainly crash things.

@javakhishvili any ideas here?

[dvdjv]

Hey @baude
Tested it with podman-4.2.0 . Still reproduces.

There's an easier way to reproduce this issue, though. Check this out:

# No stupid variables, podman works as expected
PS C:\Users\David> podman run -ti --rm alpine echo "Hello, world!"
Hello, world!

# Let's create a var with a stupid name! podman errors out
PS C:\Users\David> ${env:Dummy Variable} = "Dummy"
PS C:\Users\David> podman run -ti --rm alpine echo "Hello, world!"
Error: error parsing host environment variables: name "Dummy Variable" has white spaces, poorly formatted name

# Now let's remove the stupid variable, it works again.
PS C:\Users\David> rm 'Env:\Dummy Variable'
PS C:\Users\David> podman run -ti --rm alpine echo "Hello, world!"
Hello, world!
PS C:\Users\David>

Now we have a compatibility issue between Windows (white spaces are allowed in env var keys) and *nix (no whites paces are allowed). So we can't pass such variables to the Linux VM. Would it make sense to emit a warning and filter out such variables instead?

[rhatdan]

Looks like Podman is examining the environment even when it is not using it...
Seems https://github.com/containers/podman/blob/main/pkg/env/env.go#L90-L92 should be removed.

But would like to know why we are parsing the users environment.

[baude]

I'm not sure it should be removed. I'm setting up a better windows dev environment so i can get a better look. It might be a case of being aggressive with checking the formats. And it might be misplaced .. hold tight

[n1hility]

IMO skipping non-mappable Windows env entries as @javakhishvili suggests is probably the right approach. If someone is passing an env into a container, then they need to conform to the posix/unix/linux requirements anyway, so no harm done there.

[rhatdan]

The weird thing here from his example is he was not passing the environment into a container?

From @javakhishvili example it looks like Podman is examining the users environment regardless if it is using it in a container, or am I mistaken.

[dvdjv]

@rhatdan You're right. It doesn't depend on whether the var is passed to a container or not.