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-imageAssignee: Clement Verna <clems.verna>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 38CC: 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: 2024-05-28 13:35:45 UTC 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 Marcin Sobczyk 2023-07-26 09:34:17 UTC
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

Comment 1 Aoife Moloney 2024-05-28 13:35:45 UTC
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.