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: NEW
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: 2023-07-26 09:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
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


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