podman cannot mount volumes with external symlinks

[joequant]

/kind bug

Description

Podman volumes with external symlinks does not seem to be mountable

Steps to reproduce the issue:

1. Create volume with symlink which references files outside of the volume. For example symbolic link to ../foo

2. Try to mount the volume.

3. Volume does not mount

Describe the results you received:
Volume fails to mount

Describe the results you expected:

Volume should mount, and when I enter the image, I should see the symbolic link point to the file within the context of the mounted volume. This is the behavior in docker. Also these sorts of symbolic links are very common in directory /etc which points to /usr/share or to other directories outside the volume

---

Error: unable to start container 34e9c7636cd474d63741b93ecbd0dabfcab44aad263cedac4b4aa65ef93c5460: error copying content from container 34e9c7636cd474d63741b93ecbd0dabfcab44aad263cedac4b4aa65ef93c5460 into volume demo_etc: invalid symlink "/home/joe/.local/share/containers/storage/volumes/demo_etc/_data/httpd/logs" -> "../../var/log/httpd"

---

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:
[joe@big-apple bench]$ podman version
Version: 2.0.0-dev
RemoteAPI Version: 1
Go Version: go1.14.2
OS/Arch: linux/amd64

**Output of `podman info --debug`:**

[joe@big-apple SPECS]$ 
  configFile: /home/joe/.config/containers/storage.conf
  containerStore:
    number: 9
    paused: 0
    running: 5
    stopped: 4
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/joe/.local/share/containers/storage
  graphStatus: {}
  imageStore:
    number: 36
  runRoot: /run/user/1000/containers
  volumePath: /home/joe/.local/share/containers/storage/volumes
version:
  Built: 0
  GitCommit: ""
  GoVersion: go1.14.2
  OsArch: linux/amd64
  RemoteAPIVersion: 1
  Version: 2.0.0-dev

Package info (e.g. output of rpm -q podman or apt list podman):

podman-2.0.0-0.1.dev.git8857ba2.mga8

Additional environment details (AWS, VirtualBox, physical, etc.):

[mheon]

Create a volume how? podman volume create, mount into a container, add a symlink in the volume?

[joequant]

The work flow is 1) create a container with symlinks 2) set up a podman-compose or podman to mount a named volume with the directory with symlinks 3) podman tries to populate the named volume by copying the files from the container 4) and it fails It appears that there is an internal check that throws an exception when podman does a copy. I'd suggest changing that exception into a warning. The use case is that I have a container but I'd like to persist /etc and /etc has a symlinks to files in /usr/share

…

On Mon, Apr 27, 2020 at 11:55 PM Matthew Heon ***@***.***> wrote: Create a volume how? podman volume create, mount into a container, add a symlink in the volume? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6003 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWGAGLOMUXSPEJZUXYPTF3ROWTI5ANCNFSM4MSA6Q3Q> .

[rhatdan]

I believe this check it to prevent CVEs, We might be a little more strict then we need to be.

[mheon]

We're using c/storage's CopyWithTar() to accomplish the actual copy-up. I think you may be right that this is a CVE fix for other uses of that function (it's also used for podman cp and Dockerfile ADD instructions, I believe). I think the issue here is the ../../ component of the link, which we see as a potential attempt to escape the container.

[joequant]

Any suggestions on how to fix? I can add a flag to CopyWithTar to avoid the check when copying a volume

[mheon]

That's definitely one way to do it. I somewhat wonder if we really need all of CopyWithTar for what should be a relatively simple copy.

[joequant]

Is there any reason why I can't just replace CopyWithTar with a call to shutil?

[joequant]

put in a fix in #6279

This turned out to be a very tricky patch to get right.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@joequant What is going on with this one?

[joequant]

I have a patch that fixes the issue, but it turns out to be quite difficult to get everything right.

Unfortunately, the solution for me is to keep using docker until someone else can figure out how to address this issue.

[rhatdan]

@baude PTAL

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[Forceu]

Any update on this issue?

[mheon]

I imagine that reworking our copyup code to use Buildah's copier package should solve this.

[rhatdan]

@vrothberg did your rework of the copier code fix this issue?

[mheon]

I don't believe he hit this code - only podman cp. Given the way he structured the copy code, sharing that for copy-up no longer seems feasible. Using the Buildah Copier package still seems like the best way to do this though.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@mheon Any chance you can work on this one?

[agates]

If it helps for testing, I received this when trying to run paloaltonetworks/minemeld

[mheon]

@rhatdan I can take a look once I'm done with what I'm working on now.

[mheon]

Fix in #9308