macOS: resolve volume source symlinks to fix /tmp mounts

[Banana-Cultist]

This PR fixes an issue where mounting volumes from directories that are symbolic links on the host (specifically /tmp on macOS) would fail or result in mounting the wrong directory inside the VM.

On macOS, /tmp is a symlink to /private/tmp. When a user runs podman run -v /tmp/foo:/mnt ..., the Podman client sends the path /tmp/foo to the Linux VM. The Linux VM has its own /tmp directory while also mounting /private from the host. This results in a statfs error or the container mounting the VM's local /tmp instead of the user's intended host directory (/private/tmp).

This PR updates the volume spec generation logic in pkg/specgen to resolve symbolic links for absolute host paths on macOS before the spec is sent to the backend. This ensures that /tmp/foo is converted to /private/tmp/foo, which correctly maps to the shared file system mount inside the Podman machine.

A new unit test TestResolveVolumeSourcePathTmpSymlink has been added in pkg/specgen.

I also manually verified the fix using a podman-remote binary built from this branch:

Reproduction Command:

mkdir -p /tmp/test-vol/data
touch /tmp/test-vol/data/hello.txt
./bin/darwin/podman run --rm -v /tmp/test-vol/data:/mnt alpine ls /mnt

Before:
Error: statfs /tmp/test-vol/data: no such file or directory

After:
hello.txt

Fixes #27468

Checklist

Ensure you have completed the following checklist for your pull request to be reviewed:

• Certify you wrote the patch or otherwise have the right to pass it on as an open-source patch by signing all
  commits. (git commit -s). (If needed, use git commit -s --amend). The author email must match
  the sign-off email address. See CONTRIBUTING.md
  for more information.
• Referenced issues using Fixes: #00000 in commit message (if applicable)
• Tests have been added/updated (or no tests are needed)
• Documentation has been updated (or no documentation changes are needed)
• All commits pass make validatepr (format/lint checks)
• Release note entered in the section below (or None if no user-facing changes)

Does this PR introduce a user-facing change?

Fixed an issue on macOS where volume mounts from `/tmp` (or other symlinked host directories) failed to mount the correct host path.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Banana-Cultist
Once this PR has been reviewed and has the lgtm label, please assign luap99 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Honny1]

I have just one nit about the test. Also, I realized that this issue also impacts the local API, but it is unrelated to this PR. I will create an issue for that.

[Honny1]

Use t.TempDir() for automatic cleanup. According to the implementation, this calls MkdirTemp using the default temporary path derived from the TMPDIR environment variable (MkdirTemp, TempDir() string)). You can use t.Setenv to force this to /tmp.

Suggested change

	dir, err := os.MkdirTemp("/tmp", "podman-vol-")
	dir := t.TempDir()

[Luap99]

Thanks, but I am not sure this make sense.

First of all this changes the behavior for macos only making it rather confusing if you compare it to podman-remote on linux.

But second, most importantly this is a a breaking change. In general there is not direct relation between the path on the client and on the server. The actual mounts happen server side so if we resolve the path on the client it means it is impossible to mount /tmp/somedir on the server because the client always resolves it first.
On the other hand if we don't resolve like currently we pass the path as is and it works just fine. And if a users wants to resolve the link they can just do it themselves before calling podman.
Our docs never claim to mount /tmp with podman machine, we do mount /private so I think saying we must fix /tmp mounts is wrong. There is also no guarantee that the symlink target exists on the server.

As such I would recommend to close the issue as wontifx but I am interesting in @baude @mheon @l0rd and @ashley-cui opinions on this.

[baude]

should we block /tmp mounts in the remote client?

[Luap99]

should we block /tmp mounts in the remote client?

Why though? The mount is valid and needed if I do want to mount the real serve side /tmp.