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

Allow the use of unshare for unprivileged user namespaces #317

Open
DrDaveD opened this issue Feb 2, 2022 · 9 comments
Open

Allow the use of unshare for unprivileged user namespaces #317

DrDaveD opened this issue Feb 2, 2022 · 9 comments

Comments

@DrDaveD
Copy link

DrDaveD commented Feb 2, 2022

Currently if you try to allocate an unprivileged user namespace inside of shifter, even if the host allows it (e.g. on Perlmutter), an error is returned from the unshare command:

"unshare: unshare failed: Operation not permitted"

Can that be changed to be allowed? With that we should be able to run cvmfsexec and unprivileged singularity under shifter.

@scanon
Copy link
Member

scanon commented Feb 15, 2022

@DrDaveD I don't think this is anything we are explicitly doing in Shifter. I think the kernel doesn't allow it for some reason. But I'm not 100% certain.

@DrDaveD
Copy link
Author

DrDaveD commented Feb 15, 2022

Normally the kernel allows nesting of unprivileged namespaces.

On the host, can you run unshare -rm and inside that unshare -rm again? Can you run unshare -rm directly inside of shifter?

Docker deliberately blocks the unshare() system call (along with others) using seccomp by default. Shifter doesn't do something like that? There I need to pass the startup option --security-opt seccomp=unconfined to turn that off.

@scanon
Copy link
Member

scanon commented Feb 16, 2022

I'm not certain but I think this may be the reason...

From the unshare manpage...

   EPERM (since Linux 3.9)
          CLONE_NEWUSER was specified in flags and the caller is in
          a chroot environment (i.e., the caller's root directory
          does not match the root directory of the mount namespace
          in which it resides).

I thinking maybe this is kicking in for Shifter. I would have to dig through the kernel code to know for sure.

@DrDaveD
Copy link
Author

DrDaveD commented Feb 16, 2022

Good find, that does look like a likely explanation. Could shifter use a mount namespace before doing chroot? That's exactly what unshare -rm creates.

@DrDaveD
Copy link
Author

DrDaveD commented Feb 16, 2022

It's possible that chroot itself doesn't work in a mount namespace, at least an unprivileged one. In cvmfsexec I ended up having to use pivot_root instead but it accomplished the same purpose.

@scanon
Copy link
Member

scanon commented Feb 16, 2022

Shifter does use the mount namespace in the case where you don't use the WLM integration (which is how I was testing it). This could be a side effect of how some of the mounts are done in the name space but I'm not sure.

@DrDaveD
Copy link
Author

DrDaveD commented Feb 17, 2022

Maybe it needs pivot_root instead of chroot?

@scanon
Copy link
Member

scanon commented Mar 4, 2022

@DrDaveD I'll take a look. It may take me a bit to set up a test instance, but I'll try to experiment and reply.

@hufnagel
Copy link

hufnagel commented Apr 4, 2022

Any news on this (has been a month...)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants