Repository navigation
[Windows] White spaces in environment variables' names prevent containers from starting #15251
Description
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:
-
Install IntelliJ Idea
-
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.
Activity
baude commentedon Aug 9, 2022
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 commentedon Aug 9, 2022
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 commentedon Aug 19, 2022
@n1hility PTAL
baude commentedon Aug 19, 2022
@mheon @n1hility please note I have assigned this to myself ... and i'm working on it.
n1hility commentedon Aug 19, 2022
@baude cool thanks
baude commentedon Aug 22, 2022
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 commentedon Aug 22, 2022
Hey @baude
Tested it with
podman-4.2.0. Still reproduces.There's an easier way to reproduce this issue, though. Check this out:
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 commentedon Aug 22, 2022
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 commentedon Aug 22, 2022
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 commentedon Aug 22, 2022
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 commentedon Aug 23, 2022
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 commentedon Aug 23, 2022
@rhatdan You're right. It doesn't depend on whether the var is passed to a container or not.
Allow podman to run in an environment with keys containing spaces