Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

podman cannot mount volumes with external symlinks #6003

Closed
joequant opened this issue Apr 27, 2020 · 22 comments · Fixed by #9308
Closed

podman cannot mount volumes with external symlinks #6003

joequant opened this issue Apr 27, 2020 · 22 comments · Fixed by #9308
Assignees
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@joequant
Copy link

/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.):

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Apr 27, 2020
@mheon
Copy link
Member

mheon commented Apr 27, 2020

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

@joequant
Copy link
Author

joequant commented Apr 28, 2020 via email

@rhatdan
Copy link
Member

rhatdan commented Apr 28, 2020

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

@mheon
Copy link
Member

mheon commented Apr 28, 2020

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
Copy link
Author

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

@mheon
Copy link
Member

mheon commented May 10, 2020

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
Copy link
Author

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

joequant added a commit to joequant/libpod that referenced this issue May 17, 2020
This patch uses termie/go-shutil to copy containers rather than
tar.  The problem with tar is that it does not copy symlinks pointing
outside of the volume.
joequant added a commit to joequant/libpod that referenced this issue May 17, 2020
This patch uses internal copy to copy containers rather than
tar.  The problem with tar is that it does not copy symlinks pointing
outside of the volume.
joequant added a commit to joequant/libpod that referenced this issue May 17, 2020
This patch uses internal copy to copy containers rather than
tar.  The problem with tar is that it does not copy symlinks pointing
outside of the volume.
joequant added a commit to joequant/libpod that referenced this issue May 17, 2020
This patch uses internal copy to copy containers rather than
tar.  The problem with tar is that it does not copy symlinks pointing
outside of the volume.
joequant added a commit to joequant/libpod that referenced this issue May 17, 2020
This patch uses internal copy to copy containers rather than
tar.  The problem with tar is that it does not copy symlinks pointing
outside of the volume.
joequant added a commit to joequant/libpod that referenced this issue May 17, 2020
This patch uses internal copy to copy containers rather than
tar.  The problem with tar is that it does not copy symlinks pointing
outside of the volume.
joequant added a commit to joequant/libpod that referenced this issue May 19, 2020
This patch uses internal copy to copy containers rather than
tar.  The problem with tar is that it does not copy symlinks pointing
outside of the volume.
joequant added a commit to joequant/libpod that referenced this issue May 19, 2020
This patch uses internal copy to copy containers rather than
tar.  The problem with tar is that it does not copy symlinks pointing
outside of the volume.
@joequant
Copy link
Author

put in a fix in #6279

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

@github-actions
Copy link

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

@rhatdan
Copy link
Member

rhatdan commented Jun 19, 2020

@joequant What is going on with this one?

@joequant
Copy link
Author

joequant commented Aug 9, 2020

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
Copy link
Member

rhatdan commented Aug 10, 2020

@baude PTAL

@baude baude assigned mheon and unassigned baude Sep 2, 2020
@github-actions
Copy link

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

@Forceu
Copy link

Forceu commented Nov 23, 2020

Any update on this issue?

@mheon
Copy link
Member

mheon commented Nov 23, 2020

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

@rhatdan
Copy link
Member

rhatdan commented Dec 24, 2020

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

@mheon
Copy link
Member

mheon commented Dec 24, 2020

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
Copy link

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

@rhatdan
Copy link
Member

rhatdan commented Jan 25, 2021

@mheon Any chance you can work on this one?

@agates
Copy link

agates commented Jan 25, 2021

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

@mheon
Copy link
Member

mheon commented Jan 25, 2021

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

@mheon mheon added the In Progress This issue is actively being worked by the assignee, please do not work on this at this time. label Feb 9, 2021
mheon added a commit to mheon/libpod that referenced this issue Feb 10, 2021
The old copy-up implementation was very unhappy with symlinks,
which could cause containers to fail to start for unclear reasons
when a directory we wanted to copy-up contained one. Rewrite to
use the Buildah Copier, which is more recent and should be both
safer and less likely to blow up over links.

At the same time, fix a deadlock in copy-up for volumes requiring
mounting - the Mountpoint() function tried to take the
already-acquired volume lock.

Fixes containers#6003

Signed-off-by: Matthew Heon <mheon@redhat.com>
mheon added a commit to mheon/libpod that referenced this issue Feb 10, 2021
The old copy-up implementation was very unhappy with symlinks,
which could cause containers to fail to start for unclear reasons
when a directory we wanted to copy-up contained one. Rewrite to
use the Buildah Copier, which is more recent and should be both
safer and less likely to blow up over links.

At the same time, fix a deadlock in copy-up for volumes requiring
mounting - the Mountpoint() function tried to take the
already-acquired volume lock.

Fixes containers#6003

Signed-off-by: Matthew Heon <mheon@redhat.com>
mheon added a commit to mheon/libpod that referenced this issue Feb 10, 2021
The old copy-up implementation was very unhappy with symlinks,
which could cause containers to fail to start for unclear reasons
when a directory we wanted to copy-up contained one. Rewrite to
use the Buildah Copier, which is more recent and should be both
safer and less likely to blow up over links.

At the same time, fix a deadlock in copy-up for volumes requiring
mounting - the Mountpoint() function tried to take the
already-acquired volume lock.

Fixes containers#6003

Signed-off-by: Matthew Heon <mheon@redhat.com>
mheon added a commit to mheon/libpod that referenced this issue Feb 10, 2021
The old copy-up implementation was very unhappy with symlinks,
which could cause containers to fail to start for unclear reasons
when a directory we wanted to copy-up contained one. Rewrite to
use the Buildah Copier, which is more recent and should be both
safer and less likely to blow up over links.

At the same time, fix a deadlock in copy-up for volumes requiring
mounting - the Mountpoint() function tried to take the
already-acquired volume lock.

Fixes containers#6003

Signed-off-by: Matthew Heon <mheon@redhat.com>
@mheon
Copy link
Member

mheon commented Feb 10, 2021

Fix in #9308

mheon added a commit to mheon/libpod that referenced this issue Feb 10, 2021
The old copy-up implementation was very unhappy with symlinks,
which could cause containers to fail to start for unclear reasons
when a directory we wanted to copy-up contained one. Rewrite to
use the Buildah Copier, which is more recent and should be both
safer and less likely to blow up over links.

At the same time, fix a deadlock in copy-up for volumes requiring
mounting - the Mountpoint() function tried to take the
already-acquired volume lock.

Fixes containers#6003

Signed-off-by: Matthew Heon <mheon@redhat.com>
mheon added a commit to mheon/libpod that referenced this issue Feb 10, 2021
The old copy-up implementation was very unhappy with symlinks,
which could cause containers to fail to start for unclear reasons
when a directory we wanted to copy-up contained one. Rewrite to
use the Buildah Copier, which is more recent and should be both
safer and less likely to blow up over links.

At the same time, fix a deadlock in copy-up for volumes requiring
mounting - the Mountpoint() function tried to take the
already-acquired volume lock.

Fixes containers#6003

Signed-off-by: Matthew Heon <mheon@redhat.com>
mheon added a commit to mheon/libpod that referenced this issue Feb 11, 2021
The old copy-up implementation was very unhappy with symlinks,
which could cause containers to fail to start for unclear reasons
when a directory we wanted to copy-up contained one. Rewrite to
use the Buildah Copier, which is more recent and should be both
safer and less likely to blow up over links.

At the same time, fix a deadlock in copy-up for volumes requiring
mounting - the Mountpoint() function tried to take the
already-acquired volume lock.

Fixes containers#6003

Signed-off-by: Matthew Heon <mheon@redhat.com>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants