-
Notifications
You must be signed in to change notification settings - Fork 98
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
Running Singularity in a user namespace created by an unprivileged user doesn't work #2698
Comments
Please could you give a bit more context:
|
Did some quick digging, and may be able to solve this without additional context. For the diff --git a/internal/pkg/ociimage/unpack.go b/internal/pkg/ociimage/unpack.go
index fdbc132d7..55cbd0736 100644
--- a/internal/pkg/ociimage/unpack.go
+++ b/internal/pkg/ociimage/unpack.go
@@ -16,7 +16,9 @@ import (
umocilayer "github.com/opencontainers/umoci/oci/layer"
"github.com/opencontainers/umoci/pkg/idtools"
"github.com/sylabs/singularity/v4/internal/pkg/util/fs"
+ "github.com/sylabs/singularity/v4/pkg/util/namespaces"
"github.com/sylabs/singularity/v4/pkg/sylog"
+
)
// isExtractable checks if we have extractable layers in the image. Shouldn't be
@@ -69,7 +71,8 @@ func UnpackRootfs(_ context.Context, srcImage v1.Image, destDir string) (err err
}
// Allow unpacking as non-root
- if os.Geteuid() != 0 {
+ insideUserNs, _ := namespaces.IsInsideUserNamespace(os.Getpid())
+ if os.Geteuid() != 0 || insideUserNs {
mapOptions.Rootless = true
uidMap, err := idtools.ParseMapping(fmt.Sprintf("0:%d:1", os.Geteuid())) |
The With
At present this is not working, as a wrapped extraction of an image is failing to honour the You can workaround this issue, at present, via creating a sandbox dir and then running with
|
If we are running from within a user namespace, then use rootless OCI layer with umoci. This permits the extraction to complete when singularity is run under `unshare -r`. Part of sylabs#2698
If singularity is executed with `--userns/-u` then it should also use a user namespace where it executes `unsquashfs` in a wrapped manner. Previously the `unsquashfs` wrapping was without `--userns/-u` in a setuid installation. This caused extraction to fail from within a non-root-mapped user namespace (e.g. `unshare -c`). Part of sylabs#2698
If we are running from within a user namespace, then use rootless OCI layer with umoci. This permits the extraction to complete when singularity is run under `unshare -r`. Part of sylabs#2698
If singularity is executed with `--userns/-u` then it should also use a user namespace where it executes `unsquashfs` in a wrapped manner. Previously the `unsquashfs` wrapping was without `--userns/-u` in a setuid installation. This caused extraction to fail from within a non-root-mapped user namespace (e.g. `unshare -c`). Part of sylabs#2698
If singularity is executed with `--userns/-u` then it should also use a user namespace where it executes `unsquashfs` in a wrapped manner. Previously the `unsquashfs` wrapping was without `--userns/-u` in a setuid installation. This caused extraction to fail from within a non-root-mapped user namespace (e.g. `unshare -c`). Part of sylabs#2698
If singularity is executed with `--userns/-u` then it should also use a user namespace where it executes `unsquashfs` in a wrapped manner. Previously the `unsquashfs` wrapping was without `--userns/-u` in a setuid installation. This caused extraction to fail from within a non-root-mapped user namespace (e.g. `unshare -c`). Part of sylabs#2698
If singularity is executed with `--userns/-u` then it should also use a user namespace where it executes `unsquashfs` in a wrapped manner. Previously the `unsquashfs` wrapping was without `--userns/-u` in a setuid installation. This caused extraction to fail from within a non-root-mapped user namespace (e.g. `unshare -c`). Part of sylabs#2698
If singularity is executed with `--userns/-u` then where possible it should also use a user namespace where it executes `unsquashfs` in a wrapped manner. Previously the `unsquashfs` wrapping was without `--userns/-u` in a setuid installation. This caused extraction to fail from within a non-root-mapped user namespace (e.g. `unshare -c`). Part of sylabs#2698
Hi, thanks for the quick response!
I first encountered this issue when running the commands inside a Docker container, but was able to reproduce the exact same issue on a host machine. Neither the container or the host work, but the host seemed more easily reproducible so I included that as the bug report instead.
I'm trying to create a Docker container with an application preinstalled. The app is a workflow engine and uses Singularity as one of it's container backends to run tasks. I noticed that sandboxing images could take up a small amount of time for each task, so I wanted to see how much of a difference having Singularity mount with FUSE would be. In theory the container could be set up as privileged, which would allow it to work, but it would be better if that weren't the case. I applied the patch and
My guess is because Singularity tries to cleanup twice as the same unmount command appears above:
This is probably a separate issue, but it doesn't break Singularity's functionality since the |
Thanks for the feedback. The fusermount error is indeed something that will need to be addressed differently / separately. I'll open a separate issue for that, and we can tackle it a bit later on. |
If we are running from within a user namespace, then use rootless OCI layer with umoci. This permits the extraction to complete when singularity is run under `unshare -r`. Part of sylabs#2698
If singularity is executed with `--userns/-u` then where possible it should also use a user namespace where it executes `unsquashfs` in a wrapped manner. Previously the `unsquashfs` wrapping was without `--userns/-u` in a setuid installation. This caused extraction to fail from within a non-root-mapped user namespace (e.g. `unshare -c`). Part of sylabs#2698
Version of Singularity
What version of Singularity are you using? Run:
Describe the bug
When making a namespace as an unprivileged user, either the UID in the namespace is mapped to 0 or something else. When the UID is mapped to 0 singularity thinks it is root, and tries to perform operations that it may not be permitted to do even if it's not technically root. If the UID is mapped to something else, Singularity says that it's not installed correctly as setuid means it expects to be root but isn't getting UID 0.
To Reproduce
Steps to reproduce the behavior:
To reproduce when UID is mapped to 0, the container can't be built:
Full logs here
To reproduce when UID is mapped to something else. The container is able to be built/unpacked but it can't execute:
Full logs here
Expected behavior
Singularity should be able to run the container.
OS / Linux Distribution
Which Linux distribution are you using?
Installation Method
Installed through the .deb file on the Github releases page.
Additional context
I'm trying get Singularity with FUSE mounts to run inside an unprivileged Docker container. In order to use FUSE inside an unprivileged docker container, I need to be inside a user namespace according to this issue, but Singularity doesn't work inside an unprivileged user namespace.
The text was updated successfully, but these errors were encountered: