RFE: supporting adding new bind mounts on existing containers

[jlebon]

E.g. something like podman bind-mount my-running-container /host/path:/cnt/path. This is really useful if you've got a pet container with a lot of state and would rather not rebuild it.

I've been able to do this in the past with docker containers using nsenter as described here though it'd be great if there was a built-in command to handle this.

[mheon]

I think temporary mounts would be doable - temporarily mount a new directory into a container. Permanent is more troublesome - everything in libpod is built on the assumption that the core configuration of a container is immutable.

[rhatdan]

@jlebon So you want a mount point to suddenly appear inside of the container image?

podman bind-mount my-running-container /var/lib/foobar:/var/lib/foobar:Z,ro,rshared

Would nsenter -m into the continers mount namespace and bind mount the host directory on top of the containers directory?

Relabel /var/lib/foobar to work with the SELinux label
mount -o bind /var/lib/foobar $CONTAINERROOTFS:/var/lib/foobar

[jlebon]

I think temporary mounts would be doable

I think restricting this to temporary mounts is totally reasonable. My workflow right now is that I have a helper script that spawns a new pet container if it doesn't already exist, or just resumes it if it does. So permanent modifications means modifying that launch script for the next time I recreate the container. The bind-mount command is more so that I don't have to nuke & recreate it right away.

Would nsenter -m into the continers mount namespace and bind mount the host directory on top of the containers directory?

Yes, exactly!

[rhatdan]

@mheon Any more thoughts on implementing this?

[mheon]

I think we'd want to do this as part of podman container clone whenever we get around to that

[rhatdan]

@jlebon Do you still need this or is the nsenter suggestion good enough?

[jlebon]

The nsenter hack is OK, but having a command do it all for me would be cool. Definitely don't need it, but I do want it. :) Feel free to (de)prioritize accordingly.

[mheon]

@rhatdan We can close this and toss it as a use case for container clone (which also closes #376)

[debarshiray]

While the original RFE still holds, let me describe the hack that Toolbox uses to somewhat ameliorate this. It lets older containers pick up newer bind mounts added in successive Toolbox releases.

(The original idea comes from Colin Walters.)

There are two main things:

First, Toolbox uses podman create ... --volume ... --volume ... to mount huge swathes of the host's file system inside the container under /run/host. So /etc goes to /run/host/etc, /usr to /run/host/usr, /var to /run/host/var, and so on.

Second, when creating a container, Toolbox places itself as the entry-point:

$ podman create ... --volume /usr/bin/toolbox:/usr/bin/toolbox:ro ... <image> toolbox init-container ...

The toolbox init-container command takes care of the more targetted bind mounts. eg., placing the XDG_RUNTIME_DIR, /etc/machine-id and such in the right location by taking the specific file or directory from /run/host/... and bind mounting them again in the desired spot. Since the toolbox init-container implementation gets updated with the rest of /usr/bin/toolbox, this gives you the impression of adding newer bind mounts to older containers.

However, the illusion will be shattered if we need to bind mount something that's not already present in /run/host/....