aboutsummaryrefslogtreecommitdiff
path: root/libpod/container_path_resolution.go
Commit message (Collapse)AuthorAge
* libpod: fix lookup for subpath in volumesGiuseppe Scrivano2022-09-14
| | | | | | | | | a subdirectory that is below a mount destination is detected as a subpath. Closes: https://github.com/containers/podman/issues/15789 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
* libpod: rename functionGiuseppe Scrivano2022-09-14
| | | | | | | the function checks if a path is under any mount, not just bind mounts. Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
* libpod: switch to golang native error wrappingSascha Grunert2022-07-05
| | | | | | | | | 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>
* document that using libpod package directly is not supportedPaul Holzinger2022-03-23
| | | | | | | | | | We do not support using the libpod package outside of podman. There is no stable interface which can be used. Instead point users to the API and go bindings. Fixes #13086 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
* volumes: be more tolerant and fix infinite loopValentin Rothberg2021-10-28
| | | | | | | | | | | | | | | | | | | | | | Make Podman more tolerant when parsing image volumes during container creation and further fix an infinite loop when checking them. Consider `VOLUME ['/etc/foo', '/etc/bar']` in a Containerfile. While it looks correct to the human eye, the single quotes are wrong and yield the two volumes to be `[/etc/foo,` and `/etc/bar]` in Podman and Docker. When running the container, it'll create a directory `bar]` in `/etc` and a directory `[` in `/` with two subdirectories `etc/foo,`. This behavior is surprising to me but how Docker behaves. We may improve on that in the future. Note that the correct way to syntax for volumes in a Containerfile is `VOLUME /A /B /C` or `VOLUME ["/A", "/B", "/C"]`; single quotes are not supported. This change restores this behavior without breaking container creation or ending up in an infinite loop. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2014149 Signed-off-by: Valentin Rothberg <rothberg@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>
* Fix infinite loop in isPathOnVolumeSlava Bacherikov2021-05-06
| | | | | | | | | | filepath.Dir in some cases returns `.` symbol and calling this function again returns same result. In such cases this function never returns and causes some operations to stuck forever. Closes #10216 Signed-off-by: Slava Bacherikov <slava@bacher09.org>
* 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>
* Enable whitespace linterPaul Holzinger2021-02-11
| | | | | | | | Use the whitespace linter and fix the reported problems. [NO TESTS NEEDED] Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
* Enable stylecheck linterPaul Holzinger2021-02-11
| | | | | | | | Use the stylecheck linter and fix the reported problems. [NO TESTS NEEDED] Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
* workdir presence checksValentin Rothberg2021-01-26
| | | | | | | | | | | | | | | | | | A container's workdir can be specified via the CLI via `--workdir` and via an image config with the CLI having precedence. Since images have a tendency to specify workdirs without necessarily shipping the paths with the root FS, make sure that Podman creates the workdir. When specified via the CLI, do not create the path, but check for its existence and return a human-friendly error. NOTE: `crun` is performing a similar check that would yield exit code 127. With this change, however, Podman performs the check and yields exit code 126. Since this is specific to `crun`, I do not consider it to be a breaking change of Podman. Fixes: #9040 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
* libpod: add (*Container).ResolvePath()Valentin Rothberg2021-01-26
Add an API to libpod to resolve a path on the container. We can refactor the code that was originally written for copy. Other functions are requiring a proper path resolution, so libpod seems like a reasonable home for sharing that code. Signed-off-by: Valentin Rothberg <rothberg@redhat.com>