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

/kind bug

Description

To differentiate between Podman installed inside WSL2 via apt and Podman installed via a binary installer using a WSL2 backend, I'll call the former Podman in WSL2 and the latter Podman on Windows. Now, to the issue:

If providing a path to a custom seccomp profile, using Podman on Windows, we must provide an absolute, WSL path, which is unusual since mounting volumes or otherwise providing paths expects normal Windows paths. We also cannot use relative paths. If providing paths for Podman in WSL2, we can use relative paths and absolute (WSL2) paths, both of which work as expected.

Steps to reproduce the issue:

1. Install WSL2 and Ubuntu 22.04 on WSL2
2. Install Podman for Windows via the MSI installer and Podman via apt in WSL2.

Once everything has been installed, save the following to seccomp.json in the CWD:

{"defaultAction": "SCMP_ACT_ALLOW"}

For Podman on Windows (run using CMD, but using bash syntax highlighting for better clarity), try the following:

# relative path, try just the profile name
> podman run -it --rm --security-opt seccomp=seccomp.json ubuntu:20.04 bash -c "echo $(whoami)"
Error: opening seccomp profile failed: open seccomp.json: no such file or directory
# relative path, try pointing to the current directory
> podman run -it --rm --security-opt seccomp=.\seccomp.json ubuntu:20.04 bash -c "echo $(whoami)"
Error: opening seccomp profile failed: open seccomp.json: no such file or directory
# try an absolute path, using the regular windows syntax
> podman run -it --rm --security-opt seccomp=%CD%\seccomp.json ubuntu:20.04 bash -c "echo $(whoami)"
Error: opening seccomp profile failed: open C:\Users\ahusz\git\rust-cpp-hello-word\seccomp.json: no such file or directory
# convert it to a WSL path, and try again
# we do this via `wsl -e wslpath -a %cd%\seccomp.json`, which the value of is stored in `%PATH%`
# this works
> podman run -it --rm --security-opt seccomp=%PATH% ubuntu:20.04 bash -c "echo $(whoami)"
root

Now, if we use Podman In WSL2, we get the expected results:

# relative path, try just the profile name
$ podman run -it --rm --security-opt seccomp=seccomp.json ubuntu:20.04 bash -c 'echo $(whoami)'
root
# relative path, try pointing to the current directory
$ podman run -it --rm --security-opt seccomp=./seccomp.json ubuntu:20.04 bash -c 'echo $(whoami)'
root
# try an absolute path, using unix paths since it's WSL
$ podman run -it --rm --security-opt seccomp="$PWD"/seccomp.json ubuntu:20.04 bash -c 'echo $(whoami)'
root

Describe the results you received/expected:

For Podman on Windows, relative and Windows paths do not work, and only WSL paths work for the seccomp profile, which is unexpected since we'd expected the path to be relative to the host. For Podman in WSL2, relative paths and absolute, UNIX paths work.

For contrast, if we're mounting a volume from the host into the container, we can use relative paths or Windows paths, such as:

# relative
> podman run -it --rm -v target:/target ubuntu:20.04 bash -c "ls /target"
armv7-linux-androideabi  debug
# absolute
> podman run -it --rm -v %cd%\target:/target ubuntu:20.04 bash -c "ls /target"
armv7-linux-androideabi  debug
# absolute, WSL path
# the value pf `wsl -e wslpath -a %cd%` is stored in `%PATH%`, or the absolute WSL path of the current directory
> podman run -it --rm -v %PATH%/target:/target ubuntu:20.04 bash -c "ls /target"
armv7-linux-androideabi  debug

So relative, WSL, and absolute Windows paths all work when mounting volumes, but not when providing seccomp profiles.

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

These errors always happen, but the version info is as follows:

Output of podman version: Podman on Windows:

Client:       Podman Engine
Version:      4.1.0
API Version:  4.1.0
Go Version:   go1.16.15
Git Commit:   e4b03902052294d4f342a185bb54702ed5bed8b1
Built:        Fri May  6 08:47:05 2022
OS/Arch:      windows/amd64

Server:       Podman Engine
Version:      4.1.0
API Version:  4.1.0
Go Version:   go1.16.15
Built:        Mon May 30 11:02:41 2022
OS/Arch:      linux/amd64

Output of podman version: Podman in WSL2:

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.3
Built:        Wed Dec 31 18:00:00 1969
OS/Arch:      linux/amd64

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)

Yes. The issue isn't related to the version, the newest version installed via the MSI installer is what fails.

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

Physical machine, Windows 10 Home install.