You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On two 64-bit Fedora 21 machines running current kernels and configured without SELinux, current git tip fails self tests with:
--- FAIL: TestCloneNEWUSERAndRemapNoRootDisableSetgroups-4 (0.01s)
exec_linux_test.go:45: Cmd failed with err fork/exec /usr/bin/whoami: operation not permitted, output:
FAIL
FAIL syscall 0.063s
Looking at strace output, the specific failure is an EPERM error writing to /proc/<new pid>/gid_map, although the open() succeeds; specifically it is trying to write '0 19 1\n' to the file. 19 is my UID, but it is not any of my GIDs. What's happening is that the test code implicitly assumes you are in a group that has the same numeric ID as your UID, which is not a safe assumption. When you are not, the kernel rejects the attempt to remap GID 0 to a group that you are not a member of.
I believe that the correct fix is to change things to pass whoamiCmd() the target GID explicitly. For the root versions this is 0, for the non-root versions it is os.Getgid(). A trial run of such a change passes all tests.
The text was updated successfully, but these errors were encountered:
We've solved the problem that this issue describes, so you are encountering a different problem. Please open a new issue. Thanks.
It would be helpful if you could "go test -c syscall" and then "strace -f syscall.test -test.run=TestCloneNEWUSERAndRemapNoRootDisableSetgroups" so that we can see exactly what is failing. Thanks.
On two 64-bit Fedora 21 machines running current kernels and configured without SELinux, current git tip fails self tests with:
Looking at strace output, the specific failure is an EPERM error writing to
/proc/<new pid>/gid_map
, although the open() succeeds; specifically it is trying to write '0 19 1\n' to the file. 19 is my UID, but it is not any of my GIDs. What's happening is that the test code implicitly assumes you are in a group that has the same numeric ID as your UID, which is not a safe assumption. When you are not, the kernel rejects the attempt to remap GID 0 to a group that you are not a member of.I believe that the correct fix is to change things to pass whoamiCmd() the target GID explicitly. For the root versions this is 0, for the non-root versions it is os.Getgid(). A trial run of such a change passes all tests.
The text was updated successfully, but these errors were encountered: