-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: StartProcess returns Errno(0)
on Linux if SYS_CAPGET
or SYS_CAPSET
fails
#57208
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
FrozenDueToAge
NeedsFix
The path to resolution is known, but the work has not been done.
OS-Linux
Milestone
Comments
Change https://go.dev/cl/456516 mentions this issue: |
Change https://go.dev/cl/456515 mentions this issue: |
Change https://go.dev/cl/456375 mentions this issue: |
Errno(0)
on Linux if the parent process fails to write Errno(0)
on Linux if SYS_CAPGET
or SYS_CAPSET
fails
gopherbot
pushed a commit
that referenced
this issue
Jan 25, 2023
The various forkAndExecInChild implementations have comments explaining that they pre-declare variables to force allocations to occur before forking, but then later use ":=" declarations for additional variables. To make it clearer that those ":=" declarations do not allocate, we move their declarations up to the predeclared blocks. For #57208. Change-Id: Ie8cb577fa7180b51b64d6dc398169053fdf8ea97 Reviewed-on: https://go-review.googlesource.com/c/go/+/456516 Auto-Submit: Bryan Mills <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
gopherbot
pushed a commit
that referenced
this issue
Jan 27, 2023
We currently check for at least three different permission bits before running tests that require root permissions: we look for UID 0, lack of an LXC container, and lack of a Docker container, and probe a number of distro-specific files in /proc and /sys. The sheer number of these checks suggests that we have probably missed at least one. Per Alan J. Perlis, “If you have a procedure with ten parameters, you probably missed some.” (And, indeed, we definitely have: a Debian patch¹ adds one more environment check!) CL 58170 added some of these container checks, but “decided to go this way instead of just skipping os.IsPermission errors because many of those tests were specifically written to check false positive permission errors.” However, we can't in general distinguish between a false-positive error and a real one caused by a container: if one is making a change to the syscall package, they should run the tests with -v and check for unexpected skips. Notably: - TestUnshare already skips itself if the command fails with an error ending in the string "operation not permitted", which could be caused by a variety of possible bugs. - The Unshare tests added in CL 38471 will fail with a permission error if CLONE_NEWNS is not supported, but it seems to me that if CLONE_NEWNS is supported — sufficient to start the process! — then Unmount must also be supported, and the test can at least check that the two are consistent. - The AmbientCaps tests should fail to start the subprocess with EINVAL or similar (not produce bogus output) if the kernel does not support ambient caps for any reason, which we can then detect. (If the subprocess fails in the way the test is concerned about, it will exit with status 2, not fail to start in the first place.) By executing the system calls and checking for permission errors, this change exposed an existing bug for AmbientCaps (filed as #57208), which was detected by the linux-arm-aws builder. For #57208. Updates #21379. Updates #14693. ¹https://sources.debian.org/patches/golang-1.19/1.19.3-1/0006-skip-userns-test-in-schroot-as-well.patch/ Change-Id: I9b167661fa1bb823168c8b50d8bbbf9643e49f76 Reviewed-on: https://go-review.googlesource.com/c/go/+/456375 Reviewed-by: Ian Lance Taylor <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Russ Cox <[email protected]> Auto-Submit: Bryan Mills <[email protected]> Reviewed-by: Alexander Morozov <[email protected]> Run-TryBot: Bryan Mills <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
FrozenDueToAge
NeedsFix
The path to resolution is known, but the work has not been done.
OS-Linux
On Linux, if the
CLONE_NEWUSER
flag is not set we write any requested UID or GID mappings in the parent process inforkAndExecInChild
after the child process has already been forked.If that fails, we write an error to the child via a pipe, which we expect the child to read and finally write back on a different pipe, which the parent reads after
forkAndExecInChild
returns.Somewhere in that sequence, the actual
errno
value is being dropped and the parent is reading errno 0 from the pipe instead of the actual error code. I have identified three likely shadowing bugs inforkAndExecInChild1
:https://cs.opensource.google/search?q=%22err1%20:%3D%22%20filepath:syscall%2Fexec_linux.go&ss=go%2Fgo
The text was updated successfully, but these errors were encountered: