Bug 2226712
| Summary: | Fedora images hosted on registry.fedoraproject.org do not have a PATH env variable defined | ||
|---|---|---|---|
| Product: | [Fedora] Fedora Container Images | Reporter: | Marcin Sobczyk <msobczyk> |
| Component: | fedora-container-image | Assignee: | Clement Verna <clems.verna> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 38 | CC: | clems.verna, fedoraproject |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Description of problem: Fedora images hosted on registry.fedoraproject.org do not have a 'PATH' environment variable defined on them: podman image inspect --format "{{.Config.Env}}" registry.fedoraproject.org/fedora:38 [DISTTAG=f38container FGC=f38 container=oci] their docker.io equivalents do: podman image inspect --format "{{.Config.Env}}" docker.io/fedora:38 [PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DISTTAG=f38container FGC=f38 FBR=f38] This fact causes subtle discrepancies when alternating between those two. While I didn't have time to dig into OCI specs to see if there's any requirement on this, it seems that having a 'PATH' env variable defined is "what docker does, so we should copy it" [1]. So if you try to build a container like this with buildah: FROM fedora:38 RUN echo "${PATH}" There will be no difference between the docker.io version and registry.fp.org one. If you try to do the same with kaniko however, the results will differ: podman run -v .:/hello:Z --workdir /hello gcr.io/kaniko-project/executor:latest --dockerfile Containerfile.docker.io --no-push ... /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin podman run -v .:/hello:Z --workdir /hello gcr.io/kaniko-project/executor:latest --dockerfile Containerfile.registry.fedoraproject.org --no-push ... /usr/local/bin:/usr/bin Kaniko follows docker's logic, but only if the user didn't define any variables [2]. I've stumbled upon a case where it does matter - I was trying to do gcc compilation during container image build done with kaniko. As soon as I hit docker.io quotas and switched to registry.fedoraproject.org I got these errors: ... checking for c compiler... no cleaning temporally files... done ERROR: gcc cannot create executables Most probably gcc relies 'PATH' variable definition to look for helper programs (cc1 in this case). You can reproduce this by trying to build a container with kaniko and this containerfile: FROM registry.fedoraproject.org/fedora:38 RUN dnf install -y gcc RUN echo "int main() {}" > /tmp/hello.c RUN gcc -v /tmp/hello.c -o /tmp/hello I think kaniko itself should be patched to follow the standard 'PATH' value if the _'PATH' var itself_ wasn't defined. Nevertheless, following the "explicit is better than implicit" rule I would propose adding 'PATH' definition to Fedora's containerfile template. I've posted an MR for this [3]. Version-Release number of selected component (if applicable): All Fedora container images on registry.fedoraproject.org are affected. [1] https://github.com/containers/buildah/commit/72e0721b2b1a28e895c2a1b1b1dd55993e3182e4 [2] https://github.com/GoogleContainerTools/kaniko/blob/885ff5f57b1cc450ea46dd76c0d48eb3b047d441/pkg/executor/build_test.go#L506 [3] https://github.com/fedora-cloud/fedora-container-release/pull/1