Bug 2226712 - Fedora images hosted on registry.fedoraproject.org do not have a PATH env variable defined
Summary: Fedora images hosted on registry.fedoraproject.org do not have a PATH env var...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora Container Images
Classification: Fedora
Component: fedora-container-image
Version: 38
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clement Verna
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-07-26 09:34 UTC by Marcin Sobczyk
Modified: 2024-05-28 13:35 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-05-28 13:35:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.