summaryrefslogtreecommitdiff
path: root/libpod/container_copy_linux.go
Commit message (Collapse)AuthorAge
* podman cp: fix ownershipValentin Rothberg2021-03-09
| | | | | | | | Make sure the files are chowned to the host/container user, depending on where things are being copied to. Fixes: #9626 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* podman cp: ignore EPERMs in rootless modeValentin Rothberg2021-03-09
| | | | | | | | | | | | Ignore permission errors when copying from a rootless container. TTY devices inside rootless containers are owned by the host's root user which is "nobody" inside the container's user namespace rendering us unable to even read them. Enable the integration test which was temporarily disabled for rootless users. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* podman cp: support copying on tmpfs mountsValentin Rothberg2021-03-04
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>