python-wasm image sets PATH and it shouldn't

[codefromthecrypt]

Describe the bug

If you inspect the python wasm image, it sets the Env variable PATH. I'm pretty sure that's a leak as the wasm runtime shouldn't need it or use this for anything.

  "architecture": "wasi",
  "config": {
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ],
    "Entrypoint": [
      "python.wasm"
    ],
    "WorkingDir": "/",
    "Labels": {
      "app.kubernetes.io/name": "python-wasm",
      "description": "CPython built for WASI, by Wasm Labs",
      "org.opencontainers.artifact.description": "CPython built for WASI, by Wasm Labs",
      "org.opencontainers.image.description": "CPython built for WASI, by Wasm Labs",
      "org.opencontainers.image.source": "https://github.com/vmware-labs/webassembly-language-runtimes",
      "org.opencontainers.image.title": "python-wasm",
      "org.opencontainers.image.vendor": "wasmlabs.dev"
    },
    "OnBuild": null
  }

Reproduction steps

Look at the config json https://ghcr.io/v2/vmware-labs/python-wasm/blobs/sha256:a3ce52210e48aa0bf6a7e8ca9c184766762819aa37b21db644428d0a35fef13f application/vnd.docker.container.image.v1+json

Expected behavior

PATH shouldn't be set unless the wasm uses it. For example, if there is a path-based lookup of lib dirs or something.

Additional context

No response

[codefromthecrypt]

I looked and basically nothing will be present from those search paths because the libs are in /usr/local/lib (not bin). There are no files in the image that are in PATH. TL;DR; pretty sure this is a bug.

$ ./car -tvf ghcr.io/vmware-labs/python-wasm:3.11.1
-rw-r--r--  14578685    Apr 25 22:24:39 python.wasm
-rw-r--r--  0   Apr 25 22:24:39 usr/local/lib/python3.11/lib-dynload/.empty
-rw-r--r--  39504   Apr 25 22:24:39 usr/local/lib/python3.11/os.py
-rw-r--r--  4094889 Apr 25 22:24:39 usr/local/lib/python311.zip

[assambar]

This is weird because we don't set any environment in the Dockerfile - https://github.com/vmware-labs/webassembly-language-runtimes/blob/main/images/python/Dockerfile.

[codefromthecrypt]

hmmm https://github.com/containers/podman/blob/3b85ab354aef57c75e31683607f2499607ba6f52/pkg/env/env.go#L18

[codefromthecrypt]

maybe more precise as looks like you are using docker https://github.com/moby/containerd/blob/96c5ae04b6784e180aaeee50fba715ac448ddb0d/oci/spec.go#L37

I've not gone into the rabbit hole to figure out if it is possible to not include this (possibly by setting PATH=)

[assambar]

Definitely worth giving it a try since that is directly exposed to the wasm module.

[assambar]

Best I could get is

            "Env": [
                "PATH="
            ],

by adding ENV PATH= to the Dockerfile

[assambar]

This looks more like a feature req for Docker than us.

[codefromthecrypt]

@assambar If you don't mind, go ahead and empty it out and put a comment somewhere that this avoids the unix defaults in moby (maybe also podman)

if you have time to raise to moby/podman that would be great, too!

I think that other tools like oras, (maybe nix?) may or may not have this PATH defaulting. I mean OCI is a generic format now even if it originated from sole OS container purpose. I think this is about the tooling history, not OCI, that this legacy thing happens.

This way we'll know if a PATH is actually in use by the wasm, because it will be non-empty. I suspect there's something somewhere that needs to scan the PATH iotw.

sg?

[assambar]

Fixed with empty PATH in current and new (python-wasm:3.11.3) images.

[codefromthecrypt]

fantastic. I'll be using these in dapr and cc you when