podman cp: support copying on tmpfs mounts

Traditionally, the path resolution for containers has been resolved on
the *host*; relative to the container's mount point or relative to
specified bind mounts or volumes.

While this works nicely for non-running containers, it poses a problem
for running ones.  In that case, certain kinds of mounts (e.g., tmpfs)
will not resolve correctly.  A tmpfs is held in memory and hence cannot
be resolved relatively to the container's mount point.  A copy operation
will succeed but the data will not show up inside the container.

To support these kinds of mounts, we need to join the *running*
container's mount namespace (and PID namespace) when copying.

Note that this change implies moving the copy and stat logic into
`libpod` since we need to keep the container locked to avoid race
conditions.  The immediate benefit is that all logic is now inside
`libpod`; the code isn't scattered anymore.

Further note that Docker does not support copying to tmpfs mounts.

Tests have been extended to cover *both* path resolutions for running
and created containers.  New tests have been added to exercise the
tmpfs-mount case.

For the record: Some tests could be improved by using `start -a` instead
of a start-exec sequence.  Unfortunately, `start -a` is flaky in the CI
which forced me to use the more expensive start-exec option.

Signed-off-by: Valentin Rothberg <rothberg@redhat.com>

1 files changed, 3 insertions, 2 deletions

diff --git a/cmd/podman/containers/cp.go b/cmd/podman/containers/cp.go
index 7887e9539..7a62d982c 100644
--- a/cmd/podman/containers/cp.go
+++ b/cmd/podman/containers/cp.go
@@ -189,8 +189,9 @@ func copyFromContainer(container string, containerPath string, hostPath string)
 		}
 
 		putOptions := buildahCopiah.PutOptions{
-			ChownDirs:  &idPair,
-			ChownFiles: &idPair,
+			ChownDirs:     &idPair,
+			ChownFiles:    &idPair,
+			IgnoreDevices: true,
 		}
 		if !containerInfo.IsDir && (!hostInfo.IsDir || hostInfoErr != nil) {
 			// If we're having a file-to-file copy, make sure to