When generating container names, podman picks the same name every time

[dfr]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

With podman 4.1.0, when creating a container without an explicit name, a randomly generated name is created each time:

fedlab1 ~/podman ‹main*› » sudo podman run --rm -i fedora cat /etc/hosts
127.0.0.1	localhost localhost.localdomain localhost4 localhost4.localdomain4
::1	localhost localhost.localdomain localhost6 localhost6.localdomain6
10.88.0.1	host.containers.internal
10.88.0.25	faaed2c156bd boring_johnson
fedlab1 ~/podman ‹main*› » sudo podman run --rm -i fedora cat /etc/hosts
127.0.0.1	localhost localhost.localdomain localhost4 localhost4.localdomain4
::1	localhost localhost.localdomain localhost6 localhost6.localdomain6
10.88.0.1	host.containers.internal
10.88.0.26	e666a4b5069c musing_swartz
fedlab1 ~/podman ‹main*› » sudo podman run --rm -i fedora cat /etc/hosts
127.0.0.1	localhost localhost.localdomain localhost4 localhost4.localdomain4
::1	localhost localhost.localdomain localhost6 localhost6.localdomain6
10.88.0.1	host.containers.internal
10.88.0.27	c3b6eb0e5100 hungry_perlman

With the latest dev build (built from hash 8266dbe), I get the same name each time:

fedlab1 ~/podman ‹main*› » sudo ./bin/podman run --rm -i fedora cat /etc/hosts
127.0.0.1	localhost localhost.localdomain localhost4 localhost4.localdomain4
::1	localhost localhost.localdomain localhost6 localhost6.localdomain6
10.88.0.1	host.containers.internal
10.88.0.31	26d0c7d09680 gallant_mahavira
fedlab1 ~/podman ‹main*› » sudo ./bin/podman run --rm -i fedora cat /etc/hosts
127.0.0.1	localhost localhost.localdomain localhost4 localhost4.localdomain4
::1	localhost localhost.localdomain localhost6 localhost6.localdomain6
10.88.0.1	host.containers.internal
10.88.0.32	e4cd25c49b31 gallant_mahavira
fedlab1 ~/podman ‹main*› » sudo ./bin/podman run --rm -i fedora cat /etc/hosts
127.0.0.1	localhost localhost.localdomain localhost4 localhost4.localdomain4
::1	localhost localhost.localdomain localhost6 localhost6.localdomain6
10.88.0.1	host.containers.internal
10.88.0.33	55fd02f7baba gallant_mahavira

The reason is that c/storage/pkg/stringid changed to use its own RNG instead of sharing the global one. It seems that GetRandomName was benefiting from stringid's seeding of the global RNG.

Steps to reproduce the issue:

1. On a host without any podman containers, run sudo podman run --rm -i fedora cat /etc/hosts and note that the container name is always the same.

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

This was tested with podman build from the hash mentioned above. It seems likely that the problem is present in v4.2.0 but I haven't tested this.

[mheon]

Our random names generator uses the Golang standard library RNG (the standard one, not the cryptographically secure one, as names aren't exactly security critical). However, it does not actually seed the random number generator; it looks like we relied on other parts of the program that also used the RNG to do so, but it seems that all of them have stopped doing so (it looks like c/storage's pkg/stringid was the last to do so, but it stopped some time between 4.0 and 4.2). So we're no longer seeding the RNG, hence entirely deterministic naming.

Solution would be to re-add seeding somewhere.

[vrothberg]

@mheon where would you add the seeding?

[dfr]

Its not clear what the right place is. Putting it somewhere in the CLI would add a requirement for other users of libpod to seed the RNG which changes the contract.

The best approach might be for Runtime to create its own RNG and change GetRandomName to take that as a parameter but that requires changing github.com/docker/docker. The simplest just adds a call to rand.Seed in (*Runtime).generateName.

[dfr]

I built v4.2.0 this morning to check and it does show this problem.

[mheon]

@vrothberg Probably Libpod's NewRuntime()? Ensure that we have a good RNG if a Libpod is started.