[Podman man] --no-hosts and base_hosts_file semantics

[th-hummel]

Hello,

running podman-4.4.1 on RHEL 8.8 or podman-5.1.0 on Fedora 40:

1. podman-run(1) states:

--no-hosts
       Do not create /etc/hosts for the container.  By default, Podman will manage  /etc/hosts,  adding  the  con‐
       tainer's  own  IP  address  and  any  hosts  from  --add-host.   --no-hosts  disables this, and the image's
       /etc/hosts will be preserved unmodified.

       This option conflicts with --add-host.

2. containers.conf(5) states:

base_hosts_file=""

       The  hosts  entries from the base hosts file are added to the containers hosts file. This must be either an
       absolute path or as special values "image" which uses the hosts file from the  container  image  or  "none"
       which means no base hosts file is used. The default is "" which will use /etc/hosts.

as a newcomer to those options I find the described semantics ambiguous and not consistent with what I can test with the two options combinatorics.

From 1. I first had deduced that --no-hosts dealt only with adding or not the 2 container/container-to-host ip addresses (+ whatever was added with --add-host). If this was the case,

--no-hosts + base_hosts_file=""

would still put host /etc/hosts file in the container, which obviously is not the case.
It seems that --no-hosts just makes the value of base_hosts_file irrelevant.

You may reply that it's what --no-hosts disables this, and the image's /etc/hosts will be preserved unmodified. means but this does not seem clear to me given the first sentence.

From2. (which states are added), I deduced that, (in case of default "" and no --no-hosts) host's /etc/hosts would be appended to image's rootfs /etc/hosts, which again does not seem to be the case.
It seems that host's /etc/hosts is "chosen" (then only container and network is added) over images's one

Finally, it seems that no matter what podman still inserts

127.0.0.1 localhost
::1 localhost

if (granted this is extreme scenario) no 127.0.0.1 or ::1 entry is found which of course is fine but differs from the default one could find for instance in ubi which is:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

It may be just me. Or maybe doc could use some clarification : what do you think ?

Thanks for your help

--
Thomas HUMMEL

[Luap99]

--no-hosts disables this, and the image's
/etc/hosts will be preserved unmodified.

This is pretty much what --no-hosts means. Podman doesn't create anything we just keep the images hosts file as is and don't over mount it without our custom one (the default). As such podman cannot add any entries, I mean sure technically we can write into the images content but it would be very ugly so we do not do that.

base_hosts_file on the other hand just serves as a base for host entries we copy up into the new hosts file. In does not effect the additional podman entries and just serves as a base. And yes you are right the localhost entries are always added because apparently this is what docker did and users complained as there host hosts file didn't include them so they wanted podman to always add them for the container.

If you like to clarify the docs PRs are always welcome.

[Luap99]

yes these special files are bind mounted because that way we can easily recreate them when the container is restarted and e.g. has a new ip.

If we would write directly to the image/container file we would need to worry about removing the old entry on stop and so on.

[th-hummel]

Ok I see.

May I ask a related but different question here: I saw that files under /run/secrets giving "magically" access to the host's subscription are handled quite the same way. But I also see that /run/secrets is whiteout'ed in layers above the base image (let's say above ubi) while obvisouly they are re-mounted at container run. Besides, obviously in the base image those are only the mount points. So why is this whiteout necessary ?

Thanks for your help

TH

[Luap99]

I don't know what creates the white-out in the image. Podman creates mounts as specified in the config (if the mounts dest does not exists in the image the oci runtime creates it)
On RHEL like systems we ship a mounts.conf like this:

$ cat /usr/share/containers/mounts.conf 
/usr/share/rhel/secrets:/run/secrets

which podman reads and injects these additional mounts.

[th-hummel]

ok,

thank you

--
Thomas Hummel

[th-hummel]

In fact I'm a bit confused. I overlooked the mounts.conf file and thought that what was bindmounted were files under /run/containers/storage/overlay-containers//userdata/run/secrets...(as I thought as well that hosts and resolv.conf came from here, don't they ?)
So why do I see those same files inside the userdata directory ?

[th-hummel]

Hello,

well after some searching and stracing I see that podman creates and uses (mounts) the userdata secrets directory only if the mounts.conf entry is not commented out. So I wonder in what case such entry (bind mount of /usr/share/rhel/secrets on/run/secrets is used as I don't find any configuration option to disable or tweak userdata creation regarding secrets handling. Or maybe it's Redhat* specific and this entry is indeed never used on those OSes ?

thanks for your help

--
Thomas HUMMEL