17 Commits

Author SHA1 Message Date
88f82ceab2 libpod: Move jointMountAndExec to container_copy_linux.go
This also moves the logic for resolving paths in running and stopped
containers tp container_copy_linux.go.

On FreeBSD, we can execute the function argument to joinMountAndExec
directly using host-relative paths since the host mount namespace
includes all the container mounts.

[NO NEW TESTS NEEDED]

Signed-off-by: Doug Rabson <dfr@rabson.org>
2022-09-20 08:36:23 +01:00
0b02d4cee6 libpod: Move container_copy_linux.go to container_copy_common.go
[NO NEW TESTS NEEDED]

Signed-off-by: Doug Rabson <dfr@rabson.org>
2022-09-20 08:36:23 +01:00
251d91699d libpod: switch to golang native error wrapping
We now use the golang error wrapping format specifier `%w` instead of
the deprecated github.com/pkg/errors package.

[NO NEW TESTS NEEDED]

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
2022-07-05 16:06:32 +02:00
d4272bed51 podman cp: do not overwrite non-dirs with dirs and vice versa
Add a new `--overwrite` flag to `podman cp` to allow for overwriting in
case existing users depend on the behavior; they will have a workaround.
By default, the flag is turned off to be compatible with Docker and to
have a more sane behavior.

Fixes: #14420
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
2022-06-10 09:42:19 +02:00
8efdbf5c4c Add API support for NoOverwriteDirNonDir
Update method signatures and structs to pass option to buildah code

```release-note
NONE
```

[NO NEW TESTS NEEDED]

Signed-off-by: Jhon Honce <jhonce@redhat.com>
2022-05-26 16:31:15 -07:00
69c479b16e enable errcheck linter
The errcheck linter makes sure that errors are always check and not
ignored by accident. It spotted a lot of unchecked errors, mostly in the
tests but also some real problem in the code.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
2022-04-29 14:06:38 +02:00
c7b16645af enable unparam linter
The unparam linter is useful to detect unused function parameters and
return values.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
2022-04-25 13:23:20 +02:00
ea08765f40 go fmt: use go 1.18 conditional-build syntax
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
2022-03-18 09:11:53 +01:00
bd09b7aa79 bump go module to version 4
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>
2022-01-18 12:47:07 +01:00
50b9d82f2e Don't use docker/pkg/archive, use containers/storage/pkg/archive
[NO NEW TESTS NEEDED]

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
2021-10-14 10:28:42 -04:00
5d6ea90e75 libpod: do not call (*container).Config()
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>
2021-09-28 17:18:02 +02:00
6fe03b25ab support container to container copy
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>
2021-07-27 15:32:23 +02:00
86c6014145 Implement --archive flag for podman cp
Signed-off-by: Matej Vasek <mvasek@redhat.com>
2021-07-01 12:01:46 +02:00
bc0e12a047 Fix problem copying files when container is in host pid namespace
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>
2021-05-19 07:55:48 -04:00
a61d70cf8e podman cp: fix ownership
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>
2021-03-09 09:02:14 +01:00
2abfef3809 podman cp: ignore EPERMs in rootless mode
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>
2021-03-09 09:02:14 +01:00
a090301bbb 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>
2021-03-04 15:43:12 +01:00