when running in podman rootless the created /var/run/docker.sock links to non existent file in podman machine

[maxandersen]

Issue Description

when you run podman rootless the /var/run/docker.sock inside the container points to a podman.sock that is not accessible to read/write

Steps to reproduce the issue

Steps to reproduce the issue
start podman rootless

ls -l /var/run/docker.sock
lrwxrwxrwx. 1 root root 23 May  5 08:18 /var/run/docker.sock -> /run/podman/podman.sock
ls -l /run/podman/podman.sock
ls: cannot access '/run/podman/podman.sock': Permission denied

this gives the issue that when ryuk is started by testcontainers it ends up with an access to a docker socket that it cannot use.

docker run -v /var/run/docker.sock:/var/run/docker.sock -e RYUK_PORT=8080 -p 8080:8080 docker.io/testcontainers/ryuk

which in turn makes testcontainers not able to "just work" even if they run with --privileged which would typically work on Linux podman runs but not on podman machine.

docker run -v /var/run/docker.sock:/var/run/docker.sock --privileged -e RYUK_PORT=8080 -p 8080:8080 docker.io/testcontainers/ryuk
docker: Error response from daemon: container create: statfs /var/run/docker.sock: permission denied.
See 'docker run --help'.

Alternative is that those who run these containers know that specifically when using via podman you use the user writable socket:

❯ docker run -v /var/run/user/501/podman/podman.sock:/var/run/docker.sock --privileged -e RYUK_PORT=8080 -p 8080:8080 docker.io/testcontainers/ryuk

2023/05/05 06:31:10 Pinging Docker...
2023/05/05 06:31:10 Docker daemon is available!
2023/05/05 06:31:10 Starting on port 8080...
2023/05/05 06:31:10 Started!

Describe the results you received

Describe the results you received

Describe the results you expected

I expected that the /var/run/docker.sock would be accessible; at least when running with priviliged.

podman info output

If you are unable to run podman info for any reason, please provide the podman version, operating system and its version and the architecture you are running.

Podman in a container

Yes

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[maxandersen]

as discussed @n1hility

[baude]

this is a good issue @maxandersen ... thanks for bringing it up. It hightlights our struggle of being rootless OR rootful and docker being largely only rootful. Symlinking the rootful socket to a rootless socket in any way seems misleading at the least.

[maxandersen]

yeah its not perfect.

If we can find a way to make it known where the right user socket is no matter if running rootless or rootfull would be a start.

Then I could at least provide a reliable way for user to configure testcontainers - optimally look into auto detection in testcontainers.

But that would possibly require podman would support docker context

[n1hility]

So I think it makes sense to adjust the /var/run/docker.sock symlink created by tmpfiles (BUT not /run/podman.sock, which I agree would be confusing); Here is why:

1. All the docker clients / APIs out of the box default to and expect to be able to talk to /var/run/docker.sock
2. Since we chose to default to rootless, yet still want to be a drop-in replacement, we already forward /var/run/docker.sock on the Host OS to rootless or rootful according to the machine setting
3. Users expect commands on the guest (in particular on Windows) to work similarly

The end result would be consistency between the guest and host with docker clients, along with this use case that Max references where a privileged container expects to be able to mount /var/run/docker.sock.

This week I can propose a small patch for discussion that would pre-set the existing ignition value for /var/run/docker.sock to be based on the rootful setting and then have some adjustment logic on start if the setting changes.

[rhatdan]

SGTM