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
syscall: TestCloneNEWUSERAndRemapNoRootDisableSetgroups failing with "operation not permitted" #11261
Comments
Thanks for the strace. It looks like it was the clone call itself that failed with EPERM. I'm not sure why that would happen. Could you run "go test syscall -test.run=TestCloneNEWUSERAndRemapNoRootSetgroupsEnableSetgroups -test.v" and attach the output here? That runs a slightly different test, which I assume is passing for you. I'd like to find out why it passes. |
According to a man page, clone with CLONE_NEWUSER can fail with EPERM if "CLONE_NEWUSER was specified in flags, but either the effective user ID or the effective group ID of the caller does not have a mapping in the parent namespace (see user_namespaces(7))." Are you running in some sort of VM? Also, are you running with SELinux enabled? |
or should I run strace on it? No, it's not a VM. It's a plain debian system, I never enabled SELinux and the debian package |
Hmmm, I was imagining that that test would be skipped. But evidently not. Yes, if you wouldn't mind, please do run strace -f on it. Thanks. |
output:
|
Thanks. Of course. The test is looking for EPERM, and it gets an EPERM from the wrong place, so it passes for the wrong reason. @LK4D4 Do you have any guess as to why clone(CLONE_NEWUSER) is failing with EPERM on this system? Any suggestions for what to look for to skip the test? |
@ianlancetaylor Only thing that I can think of on kernel 3.8+ is missing CAP_SYS_ADMIN for user or some kernel patch. Another unrealistic idea is that process becoming multithreaded earlier than it shoud. |
|
Hmmm, this is definitely unexpected on vanilla 3.16 :/ |
Do you have sysctl kernel.unprivileged_userns_clone? Perhaps the kernel has
the disabling unprivileged user namespace by default patch applied.
|
says
If I set
./all.bash passes. I should add that I never set that var to 0, it was like that by default. |
Humm, we can test this file for skip. Not sure if it's available to read from unprivileged user. Also seems like this file was removed in some kernel version. |
@ALTree If you can, please try the patch in http://golang.org/cl/11269. Thanks. |
That fixed it.
is always |
Hi @ianlancetaylor ! is the patch merged with |
It was put in master (at rev 79d4d6e) but not in the 1.5 release branch. |
Fixes for tests do not go on release branches. |
@bradfitz hi! Nope, I tried master as well, it doesn't work. |
FWIW, I see this all the time when running in a chroot. I've never got around to looking into it, but, @kamoljan are you running inside a chroot? |
@LK4D4 I am sorry, I didn't notice your message. However, I have my `strace' output (I took it from my duplicate issue)
|
here is [pid 13968] +++ exited with 1 +++ |
go version devel +dd44d49 Wed Jun 17 20:00:06 2015 +0200 linux/amd64
./all.bash
fails withOutput of
is
The text was updated successfully, but these errors were encountered: