unshare failed: Invalid argument

[Rosalie241]

• Microsoft Windows [Version 10.0.17107.1000]

I'm trying to get unshare -U to work but whenever I try to execute that command I get:

tim@localhost:/$ unshare -U
unshare: unshare failed: Invalid argument
tim@localhost:/$

it seems like WSL doesn't have User Namespaces implemented(CONFIG_USER_NS)

unshare.strace

[benhillis]

You are correct, we have not yet implemented user namespaces.

[therealkenc]

Ref CLONE_NEWUSER in #2242, which was closed (entirely reasonably) because Chrome's suid sandbox now works, but still needs --disable-namespace-sandbox.

@tim241 - if you've got another use case ("I'm trying to....") it is worth citing.

[Rosalie241]

@therealkenc well, I replaced the chroot with Void linux(because I want to write xbps package templates and the xbps-src script needs xbps-uunshare(which requires the unshare -U support if I'm correct) which is required for the way they build a package, so I /need/ the User Namespaces support. Here's an example of where it crashes:

> ~/void-packages ./xbps-src pkg linux
=> Using `/home/tim/void-packages/hostdir/binpkgs/wine-fixes' as local repository.
[*] Updating `https://repo.voidlinux.eu/current/x86_64-repodata' ...
[*] Updating `https://repo.voidlinux.eu/current/nonfree/x86_64-repodata' ...
[*] Updating `https://repo.voidlinux.eu/current/multilib/x86_64-repodata' ...
[*] Updating `https://repo.voidlinux.eu/current/multilib/nonfree/x86_64-repodata' ...
ERROR unshare (Invalid argument)
> ~/void-packages

here is where it crashes(I suspect)

EDIT: fixed broken links

[boypt]

os.exec in Go also calls unshare(CLONE_NEWUSER) , which also cause Invalid argument to all Go program calling subprocess.

hope user namespaces sooner got implimented .

[gusbemacbe]

@therealkenc, are you still working on it?

[therealkenc]

Wasn't the person "working on it". I take boypt at face value above, which would imply it was not implemented in WSL1. There is also #3282 which I suspect (but can't prove) is a side effect of chrome no longer supporting SUID sandbox (nor --no-sandbox last time I played with it, which was some time ago).

CLONE_ALLTHETHINGS is fully functional in WSL2.

[gusbemacbe]

@therealkenc, strange, I used WSL2. My issue is similar to @tim241's.

[therealkenc]

Tim241 didn't have a repro so that post was glossed in January; this was before WSL2, and thus not too surprising a fail at the time. But as it happens I'm working on something in a space (almost) related Void Linux at the moment, so you've made me look on the lark. I was able to reproduce Tim's scenario on WSL2. There is an easier repro than the ./xbps-src dance. Inside a Void chroot, just:

With the entirely predictable strace:

unshare(CLONE_NEWUSER)                  = -1 EPERM (Operation not permitted)
write(2, "unshare: ", 9unshare: )                = 9
write(2, "unshare failed", 14unshare failed)          = 14
write(2, ": Operation not permitted\n", 26: Operation not permitted

Which is nutty (at least in my somewhat sleep deprived state) because outside the chroot (back in plain 'ole Ubuntu):

Which I already knew worked because I had done it before. At a loss right this moment to guess the variable. On first glance it is hard to finger-point WSL, because user namespaces is enabled in the kernel and, well, your know, works. But it is also near-impossible to finger-point Void userspace, because I can't think of anything that Void userspace could do to make the unshare(2) fail. It isn't performing the chroot(2) proper (that makes no sense).

Reason will probably be obvious once it comes to me; if someone else doesn't beat me to it. Appreciate the submission.

[Rosalie241]

@therealkenc
I tested your repro on a native ubuntu 19.10 install (with an amd64 debian chroot)

it seems like intended behavior :)
some more research led to this:
https://unix.stackexchange.com/questions/442996/what-rule-prevents-entering-a-user-namespace-from-inside-a-chroot

[gusbemacbe]

There is an article of void-packages repo, which suggests to modify chroot's permissions.

[therealkenc]

it seems like intended behavior :)

I was afraid of that. Thanks.

[edit] Someone gets a gold star if they can concisely describe why unshare(2) returns EPERM in the scenario. There's going to be an "oh, right, that" good reason, but it isn't obvious to me atm.

[trajano]

This would be useful to automate #5090 (comment) as per https://stackoverflow.com/questions/20553039/forcing-usermod-with-running-program/56338192#comment109450754_56338192