podman ignoring /etc/containers/registries.conf and .conf.d when in rootless mode

[Hadmut Danisch]

Hi,

in contrast to docker, podman does not have a default registry to pull from, but uses /etc/containers/registries.conf and .conf.d to resolve the names.

E.g. the file coming with ubuntu, i.e. /etc/containers/registries.conf.d/shortnames.conf

resolves alpine to docker.io/library/alpine

This usually works for both root and other users (non-root mode).

In 24.04 beta it works only for root.

i.e. a

podman pull alpine

works when run as root, but not as a normal user, it can't resolve the source then. strace shows that it does not even look for a registrries.conf.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: podman 4.9.3+ds1-1build2
ProcVersionSignature: Ubuntu 6.8.0-22.22-generic 6.8.1
Uname: Linux 6.8.0-22-generic x86_64
ApportVersion: 2.28.0-0ubuntu1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: LXQt
Date: Fri Apr 19 21:29:50 2024
InstallationDate: Installed on 2024-04-19 (0 days ago)
InstallationMedia: Lubuntu 24.04 LTS "Noble Numbat" - Beta amd64 (20240410)
RebootRequiredPkgs: Error: path contained symlinks.
SourcePackage: libpod
UpgradeStatus: No upgrade log present (probably fresh install)

[Steven Garcia (garciastl)]

Hey, there. Hope all is well, all things considered.

Sorry you're running into this frustration with out-of-the-box podman. For what it's worth, I'm very new to containers (from an implementation and practical standpoint), and when I also ran into this problem (today), I found it frustrating.

It seems that the intent with the podman package is not to provide a registries.conf file by default. Why? I could speculate on the reasons: security, being one, since supply-chain poisoning is possible; there not being a "centralized" authority for containers, like there are for things like distribution updates, &c; the idea that the user will need to configure specifics and may not want to pull container images from the outside world (which I feel is both reasonable, but also kind of not).

This conclusion is based on reading the contents of the containers-registries.conf manual page (man 5 containers-registries.conf) and looking at the following post out on GitHub: https://github.com/containers/podman/issues/8896 .

First, podman will apparently look in two places for configuration files:

 /home/<username>/.config/containers (principal)
 /etc/containers (fallback)

My guess would be that you would create a registries.conf file in ~/.config/containers if you wanted to have default registry search domains that you use for containers. Aside from giving you, the user, complete control over the registries that you want to use for your container template searches, it also means no modifications or assumptions required for the base system configuration.

If you want the "Big Three" repositories, you can do the following:

 if [ ! -d ~/.config/containers ]; then
   mkdir ~/.config/containers/
   touch ~/.config/containers/registries.conf
   echo unqualified-search-registries=["registry.access.redhat.com", "registry.fedoraproject.org", "docker.io"] > ~/.config/containers/registries.conf
 elif [ ! -f ~/.config/containers/registries.conf ]; then
   touch ~/.config/containers/registries.conf
   echo unqualified-search-registries=["registry.access.redhat.com", "registry.fedoraproject.org", "docker.io"] > ~/.config/containers/registries.conf
 fi

This will:
- Create the directory "containers" in "~/.config" if it doesn't exist.
- Create the file "registries.conf" file with the Red Hat, Fedora, and Docker registries in "~/.config/containers".
- If, instead, the directory does exist, but the "registries.conf" file does not, it will create the "registries.conf" file in "~/.config/containers" with with Red Hat, Fedora, and Docker registries.

At this point, doing a "podman search nginx" or other, unqualified search (a search that doesn't specify any other elements except the package name) should work. However, it will display contributed packages, not necessarily official packages.

There is also a general warning about using registries.conf to perform searches that don't specify the registry or use potentially insecure sources of images. In short, it's a security risk:

(from the containers-registries.conf man 5 page:)

"NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES
We recommend always using fully qualified image names including the registry server (full DNS name),...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Hadmut Danisch (hadmut)]

@ Steven:

Sorry, but I wasn't looking for a dirty workaround. I was looking for a clean solution.

Your example does not at all solve the problem to use local caches or locale repositories.

It does not allow an administrator to maintain machines properly.

And worst of all: unqualified-search-registries is not recommended and considered as a security risk.

Please refrain from such crude workaround proposals.