Is there something like a volume bind translation table/chroot?

[akiross]

Hello,
I'm trying to use podman to run some CI runners (self-hosted github actions runner); the idea is to be able to run many runners over a bunch of physical servers and have different each runner be associated to a specific project/repository.

The workflows might use docker, so the podman container should be able to run docker to start a few containers: it was easy to get docker-inside-podman working by using the compatibility API by mounting /run/user/1000/podman/podman.sock to /var/run/docker.sock (at least, it seems to work in simple cases).

The problem I'm facing is that when docker is mounting volumes inside the container (e.g. via docker run -v"/home/foo:/bar") the host socket is used and the directory being mounted is at the host side (e.g. /home/foo in the example), but that might not exist at all.

This issue is somewhat similar to the one discussed here, but I'm working locally and on Linux, so I have no need to use sshfs or podman machine.

As suggested in this comment, it would be neat if I could configure podman so that, when running podman run -v /foo:/bar, the host directory /foo could be mapped to another directory, say /mnt/foo, via some translation table or "volume chroot".

I could set up multiple users, each with a different podman system service socket and a different translation table, so that each new container executed by their users will not be able to interfere with the other's (or system's).

Is something like this possible in podman 4.2 or above?

[afbjorklund]

So you are able to change paths like /var/run, but you are not able to change /foo ?

Otherwise a symlink or a bind mount, are the usual workarounds for hardcoded paths...

I guess the problem here is that you are trying to make a single-user system (Docker) into multi-user.

Running rootless docker would probably have the exact same problem, so not sure it is about podman.

[akiross]

Yes, from within the podman container I'm able to run docker container that access host resources like /var/run/ or /tmp for which the host user that ran podman has access (since host user owns the socket).

In this case, I'm using single-user podman as a docker daemon, so it should be fine 🤔 rootless docker would have the same problem yes.

I didn't understand your suggestion to use symlink or bind mount: could you give an example?

What I'm trying to do basically boils down to the ability of run, in a regular, single user, podman only situation, a translation between -v/foo:/bar into -v/something/foo:/bar, automatically, at podman config level.

The fact that I'm sharing the socket inside a podman container to run docker is just a detail put for context (maybe I'm missing more obvious solutions, I just wanted to avoid an XY problem :D)

[afbjorklund]

I was wondering why /foo -> /mnt/foo didn't solve your problem, the same way you solved your hardcoded $DOCKER_HOST ? Or in the case of your nested containers, by volume mounting a host directory.

[afbjorklund]

But the original problem was never solved, because CoreOS opened up the possibility to create empty directories in /.
So after that it was possible to create e.g. /Users as a mountpoint (for virtfs), even on the "read-only" root file system.

[akiross]

Ah, you meant to bind-mount /foo to /mnt/foo? Ok, that would not work because the mount would happen on the host side, while the -v/foo:/bar would happen on the container side, which is part of the pipeline and is therefore unknown beforehand. So I cannot know in advance whether the docker command will be docker run -v/foo:/bar or docker run -v/baz:/qux or something else. I'd like anything that can appear of the host-side of the -v flag to be rooted in a specific directory.