-
Notifications
You must be signed in to change notification settings - Fork 763
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
Add --mountns
or equivalent
#1838
Comments
Some very minimal thoughts so far:
Either way, I’m way out of my area of expertise. @giuseppe knows much more than me. |
we do a few lazy loading of files in containers/storage. That would be affected if we join a different mount namespace. Do you need to access the storage on the host only in read-only mode? In this case, I wonder if an easier approach like getting a reference to the storage from the target mount namespace and treating it like an additional image store would work. |
A friendly reminder that this issue had no activity for 30 days. |
For a use case I have, I'd like to execute a skopeo binary from inside a container image, but have it fetch data from
containers-storage:
which requires entering the host mount namespace.Several low-level commands have gradually gained support for calling
setns()
; e.g. there's nowmount -N
:-N, --namespace <ns> perform mount in another namespace
.The key benefit of this is that it's performed after dynamic linking is done, so assuming no further external binaries are run it avoids a host dependency.
But a general well known problem with
setns()
and Go is that the runtime will happily spawn threads in the background to service goroutines which may not propagate the namespace.I came across https://cs.github.com/containers/podman/blob/864288b8dabbe3eb89854b737cc7fbd93077aa1e/libpod/container_copy_linux.go?q=org%3Acontainers+setns+lang%3Ago#L17 which seems related.
Thinking about this, I wonder if we could add support to containers/storage for having it take an explicit mount namespace and perform operations there?
(I tried the below code, which worked for
skopeo inspect --mount-namespace 1 containers-storage:docker.io/library/busybox
butskopeo copy --mount-namespace 1 containers-storage:docker.io/library/busybox oci:/tmp/busybox
fails trying to access some files, I think because the accesses are running on threads spawned before we were able to unshare...so to do this right we'd need to have the main entrypoint be either C or Rust)The text was updated successfully, but these errors were encountered: