Publishing one randomized host port will lead to all host ports being randomized

[znerol]

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

/kind bug

Description

Using the --publish flag it is possible to either specify the host port explicitly or omit it. In the latter case the container runtime will allocate a random port. If multiple --publish flags are used, and at least one of them omits the host port, then all host ports will be allocated randomly.

Steps to reproduce the issue:

1. Run a container and specify one port with explicit host port mapping and one without.

   $ podman run --rm --publish 3000:3000 --publish 1234 k8s.gcr.io/pause
   

2. Examine the port mapping:

   $ podman port -l
   

Describe the results you received:

$ podman port -l
3000/tcp -> 0.0.0.0:33205
1234/tcp -> 0.0.0.0:33273

Describe the results you expected:

$ podman port -l
3000/tcp -> 0.0.0.0:3000
1234/tcp -> 0.0.0.0:NNNNN

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

$ podman version
Version:      2.2.1
API Version:  2.1.0
Go Version:   go1.14
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

Not relevant (except if the bug isn't reproducible on less exotic systems).

Package info (e.g. output of rpm -q podman or apt list podman):

Installed from kubic

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

Physical machine.

Running with --log-level debug, the following relevant lines appear:

DEBU[0000] Adding port mapping from 3000 to 3000 length 1 protocol "" 
DEBU[0000] Adding port mapping from 0 to 1234 length 1 protocol "" 
DEBU[0000] parsed reference into "[vfs@/home/lo/.local/share/containers/storage+/run/user/1000/containers]k8s.gcr.io/pause:latest" 
[...]
DEBU[0000] using systemd mode: false                    
DEBU[0000] Successfully assigned container port 3000 to host port 45799 (IP  Protocol tcp) 
DEBU[0000] Successfully assigned container port 1234 to host port 34203 (IP  Protocol tcp) 

Thus it looks like the command line parsing works correctly in parseSplitPort but fails somewhere between there an the subsequent specgen

If only explicit port mappings are specified (i.e., one '--publish 3000:3000` flag) then the loglines read:

DEBU[0000] Adding port mapping from 3000 to 3000 length 1 protocol "" 

No lines are logged from specgen/generate/parsePortMapping at all. So, maybe the problem is in the code block within if postAssignPort. When that branch is hit, then it looks like all host ports are being randomized.

[mheon]

I'll take this.

[mheon]

Confirmed, reproduces locally.

[mheon]

We definitely want a backport of this one for RHEL, I think.

[mheon]

Got it. Writing a test now to make sure we don't regress.

[znerol]

@mheon wow! Does it work with port ranges as well? I thought I found a solution by removing the ! in the condition on line 186, but that triggered problems with port ranges.

			if p.HostPort != 0 && !tmp.isInRange {

[znerol]

Also filed #8651 which might be related.

[mheon]

Fix in #8652 - you found part of the problem with tmp.isInRange, though the issue was it shouldn't have been there at all.

[znerol]

Yes, #8652 fixes both issues. Thanks!