summaryrefslogtreecommitdiff
path: root/libpod/container_copy_linux.go
Commit message (Collapse)AuthorAge
* bump go module to version 4Valentin Rothberg2022-01-18
| | | | | | | | | | | | | Automated for .go files via gomove [1]: `gomove github.com/containers/podman/v3 github.com/containers/podman/v4` Remaining files via vgrep [2]: `vgrep github.com/containers/podman/v3` [1] https://github.com/KSubedi/gomove [2] https://github.com/vrothberg/vgrep Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Don't use docker/pkg/archive, use containers/storage/pkg/archiveDaniel J Walsh2021-10-14
| | | | | | [NO NEW TESTS NEEDED] Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* libpod: do not call (*container).Config()Valentin Rothberg2021-09-28
| | | | | | | | | | | | Access the container's config field directly inside of libpod instead of calling `Config()` which in turn creates expensive JSON deep copies. Accessing the field directly drops memory consumption of a simple `podman run --rm busybox true` from 1245kB to 410kB. [NO TESTS NEEDED] Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* support container to container copyMehul Arora2021-07-27
| | | | | | | | | Implement container to container copy. Previously data could only be copied from/to the host. Fixes: #7370 Co-authored-by: Mehul Arora <aroram18@mcmaster.ca> Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* Implement --archive flag for podman cpMatej Vasek2021-07-01
| | | | Signed-off-by: Matej Vasek <mvasek@redhat.com>
* Fix problem copying files when container is in host pid namespaceDaniel J Walsh2021-05-19
| | | | | | | | | | | | | | When attempting to copy files into and out of running containers within the host pidnamespace, the code was attempting to join the host pidns again, and getting an error. This was causing the podman cp command to fail. Since we are already in the host pid namespace, we should not be attempting to join. This PR adds a check to see if the container is in NOT host pid namespace, and only then attempts to join. Fixes: https://github.com/containers/podman/issues/9985 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* 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>