For #69284Fixes#69402
Change-Id: I6350209302778ba5e44fa03d0b9e680d2b4ec192
Reviewed-on: https://go-review.googlesource.com/c/go/+/611495
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
Reviewed-by: Tim King <taking@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
(cherry picked from commit 8926ca9c5e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/613616
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
fixesgolang/go#67088
Change-Id: I42e7a8d02b161187772f147e3e136ab6e0f71d7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/585059
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
While working on CL 528798, I found out that sys.PidFD field (added
in CL 520266) is not filled in when CLONE_NEWUSER is used.
This happens because the code assumed that the parent and the child
run in the same memory space. This assumption is right only when
CLONE_VM is used for clone syscall, and the code only sets CLONE_VM
when CLONE_NEWUSER is not used.
Fix this, and add a test case (which fails before the fix).
Updates #51246.
Change-Id: I805203c1369cadd63d769568b132a9ffd92cc184
Reviewed-on: https://go-review.googlesource.com/c/go/+/542698
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Currently we are bootstrapping with Go 1.20, origRlimitNofile can
be changed to atomic.Pointer[Rlimit].
Change-Id: I00ce9d1a9030bd5dbd34e3dc6c4e38683a87be86
GitHub-Last-Rev: f2ccdb3841
GitHub-Pull-Request: golang/go#63274
Reviewed-on: https://go-review.googlesource.com/c/go/+/531516
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run 'unconvert -safe -apply' (https://github.com/mdempsky/unconvert)
Change-Id: I24b7cd7d286cddce86431d8470d15c5f3f0d1106
GitHub-Last-Rev: 022e75384c
GitHub-Pull-Request: golang/go#62662
Reviewed-on: https://go-review.googlesource.com/c/go/+/528696
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The SysProcAttr is OS-specific anyway, so it makes little sense to say
that some fields are Linux-specific (they all are anyway).
While at it, make sure to use complete sentences (add missing periods).
Change-Id: Ic0afe3920c2561fd9a657f4edab21939a8f56d57
Reviewed-on: https://go-review.googlesource.com/c/go/+/525395
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add PidFD support, so that if the PidFD pointer in SysProcAttr is not
nil, ForkExec (and thus all its users) obtains a pidfd from the kernel
during clone(), and writes the result (or -1, if the functionality
is not supported by the kernel) into *PidFD.
The functionality to get pidfd is implemented for both clone3 and clone.
For the latter, an extra argument to rawVforkSyscall is needed, thus the
change in asm files.
Add a trivial test case checking the obtained pidfd can be used to send
a signal to a process, using pidfd_send_signal. To test clone3 code path,
add a flag available to tests only.
Updates #51246.
Change-Id: I2212b69e1a657163c31b4a6245b076bc495777a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/520266
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
In CL 421441, we changed syscall to allow concurrent calls to
forkExec.
On platforms that support the pipe2 syscall that is the right
behavior, because pipe2 atomically opens the pipe with CLOEXEC already
set.
However, on platforms that do not support pipe2 (currently aix and
darwin), syscall.forkExecPipe is not atomic, and the pipes do not
initially have CLOEXEC set. If two calls to forkExec proceed
concurrently, a pipe intended for one child process can be
accidentally inherited by the other. If the process is long-lived, the
pipe can be held open unexpectedly and prevent the parent process from
reaching EOF reading the child's status from the pipe.
Fixes#61080.
Updates #23558.
Updates #54162.
Change-Id: I83edcc80674ff267a39d06260c5697c654ff5a4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/507355
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
forkAndExecInChild1 func must not acquire any locks in child, because
they might have been locked at the time of the fork. This implies to
no rescheduling, no malloc calls, and no new stack segments.
So, doing a "checkptrAlignment" is bad here, because checkptr
functions added by the instrumentation could grow the stack, which
should not be done between fork and exec calls.
Hence using a Go directive "go:nocheckptr" to forkAndExecInChild1
func,so that the compiler should not do "checkptrAlignment" when
functions marked with "go:norace".
This race detection bug was caught in go 1.21 on s390x.
Running a "./race.bash" script from "go/src" directory failed and the
bug details are provided in issue link mentioned below.
Fixes#58785
Change-Id: I254091368b0789d886acdf26f8aa8d8f5a986b24
Reviewed-on: https://go-review.googlesource.com/c/go/+/481415
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If we increased the NOFILE rlimit when starting the program,
restore the original rlimit when forking a child process.
For #46279
Change-Id: Ia5d2af9ef435e5932965c15eec2e428d2130d230
Reviewed-on: https://go-review.googlesource.com/c/go/+/476097
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
CLONE_NEWTIME can only be used with the clone3 and unshare system calls,
see 769071ac9f:
> All available clone flags have been used, so CLONE_NEWTIME uses the highest
> bit of CSIGNAL. It means that it can be used only with the unshare() and
> the clone3() system calls.
The clone3 syscall was added in Linux kernel version 5.3 and
CLONE_NEWTIME was added in version 5.6. However, it was non-functional
until version 6.3 (and stable versions with the corresponding fix [1]).
[1] https://lore.kernel.org/lkml/20230308105126.10107-1-tklauser@distanz.ch/
In case CLONE_NEWTIME is set in SysProcAttr.Cloneflags on an unsupported
kernel version, the fork/exec call will fail.
Fixes#49779
Change-Id: Ic3ecfc2b601bafaab12b1805d7f9512955a8c7e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/474356
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
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 <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Iae290216687fd1ce8be720600157fb78cc2446d0
GitHub-Last-Rev: 4fba64ecb1
GitHub-Pull-Request: golang/go#55959
Reviewed-on: https://go-review.googlesource.com/c/go/+/436881
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Implement CLONE_INTO_CGROUP feature, allowing to put a child in a
specified cgroup in a clean and simple way. Note that the feature only
works for cgroup v2, and requires Linux kernel 5.7 or newer.
Using the feature requires a new syscall, clone3. Currently this is the
only reason to use clone3, but the code is structured in a way so that
other cases may be easily added in the future.
Add a test case.
While at it, try to simplify the syscall calling code in
forkAndExecInChild1, which became complicated over time because:
1. It was using either rawVforkSyscall or RawSyscall6 depending on
whether CLONE_NEWUSER was set.
2. On Linux/s390, the first two arguments to clone(2) system call are
swapped (which deserved a mention in Linux ABI hall of shame). It
was worked around in rawVforkSyscall on s390, but had to be
implemented via a switch/case when using RawSyscall6, making the code
less clear.
Let's
- modify rawVforkSyscall to have two arguments (which is also required
for clone3);
- remove the arguments workaround from s390 asm, instead implementing
arguments swap in the caller (which still looks ugly but at least
it's done once and is clearly documented now);
- use rawVforkSyscall for all cases (since it is essentially similar to
RawSyscall6, except for having less parameters, not returning r2, and
saving/restoring the return address before/after syscall on 386 and
amd64).
Updates #51246.
Change-Id: Ifcd418ebead9257177338ffbcccd0bdecb94474e
Reviewed-on: https://go-review.googlesource.com/c/go/+/417695
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
From the append docs in the builtin package:
As a special case, it is legal to append a string to a byte slice, like this:
slice = append([]byte("hello "), "world"...)
Change-Id: Ib14039a7476873b12a3aefccd8863e8d628b9249
Reviewed-on: https://go-review.googlesource.com/c/go/+/425102
Reviewed-by: hopehook <hopehook@qq.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
The constants for these were auto-generated from the C includes
into zerrors_linux* files quite some time ago. The generator is
currently broken, but some new flags need to be added nevertheless.
As the flags won't change and the values are the same for all
architectures, we can just define them statically (as it's already
done in the runtime package):
- remove the CLONE_* constants from zerrors_linux_*.go;
- patch mkerrors.sh to not generate CLONE_ constants
(in case it will be fixed and used in the future);
- add the constants and some comments about them to exec_linux.go,
using Linux v5.17 include/uapi/sched.h as the ultimate source.
This adds the following new flags:
- CLONE_CLEAR_SIGHAND
- CLONE_INTO_CGROUP
- CLONE_NEWCGROUP
- CLONE_NEWTIME
- CLONE_PIDFD
For #51246.
Change-Id: I0c635723926218bd403d37e113ee4d62194463a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/407574
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joedian Reid <joedian@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: Ie51545eaebd22a31379bf8814a2c62b91d1d105b
Reviewed-on: https://go-review.googlesource.com/c/go/+/416934
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This is a rather large footgun, so let's mention that it sends the signal on thread termination and not process termination in the documentation.
Updates #27505
Change-Id: I489cf7136e34a1a7896067ae24187b0d523d987e
GitHub-Last-Rev: c8722b25d1
GitHub-Pull-Request: golang/go#53365
Reviewed-on: https://go-review.googlesource.com/c/go/+/412114
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A future change to gofmt will rewrite
// Doc comment.
//go:foo
to
// Doc comment.
//
//go:foo
Apply that change preemptively to all comments (not necessarily just doc comments).
For #51082.
Change-Id: Iffe0285418d1e79d34526af3520b415a12203ca9
Reviewed-on: https://go-review.googlesource.com/c/go/+/384260
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
When these packages are released as part of Go 1.18,
Go 1.16 will no longer be supported, so we can remove
the +build tags in these files.
Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs
as defined in src/cmd/dist/buildtool.go, which need to continue
to build with Go 1.4 for now.
Also reverted src/vendor and src/cmd/vendor, which will need
to be updated in their own repos first.
Manual changes in runtime/pprof/mprof_test.go to adjust line numbers.
For #41184.
Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e
Reviewed-on: https://go-review.googlesource.com/c/go/+/344955
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The minimum required Linux kernel version for Go 1.18 will be changed to
2.6.32, see #45964. The dup3 syscall was added in 2.6.27, so the
fallback to use the dup2 syscall in forkAndExecInChild1 on some
platforms can be removed.
For #45964
Change-Id: I8e04d7b5b2488990a061a080ed64ea303ad048b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/347350
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The minimum required Linux kernel version for Go 1.18 will be changed to
2.6.32, see #45964. The pipe2 syscall was added in 2.6.27, so the
fallback to use the pipe syscall in os.Pipe and syscall.forkExecPipe on
Linux can be removed.
For #45964
Change-Id: I033a534f2b39e9bafc9980c9ce980e92f1e3a136
Reviewed-on: https://go-review.googlesource.com/c/go/+/346789
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes#37217
Change-Id: I0151bb77fc4c4552d1b19c31d784943b72f84b80
Reviewed-on: https://go-review.googlesource.com/c/go/+/313653
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
This replaces five implementations scattered across low level packages.
(And I plan to use it in a sixth soon.)
Three of the five were byte-for-byte identical.
Change-Id: I3bbbeeac63723a487986c912b604e10ad1e042f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/301549
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing
'fork/exec ...: cannot allocate memory' failures from occuring when attempting
to execute commands from a Go process that has a large memory footprint.
Additionally, this should reduce the latency of fork/exec on these platforms.
Fixes#31936
Change-Id: I4e28cf0763173145cacaa5340680dca9ff449305
Reviewed-on: https://go-review.googlesource.com/c/go/+/295849
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294430
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This fixes a mistake in CL 220422. This changes code that is only
executed on Linux kernel versions earlier than 2.6.27.
Change-Id: I01280184f4d7b75e06387c38f1891e8f0a81f793
Reviewed-on: https://go-review.googlesource.com/c/go/+/244630
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
The Ctty field is a child descriptor number when Setctty is set,
but a parent descriptor when Foreground is set. This is absurd
but changing either behavior breaks existing programs.
With this change we at least document how it works.
For #29458
Change-Id: If9cf0a1a1e6ed0d4a4edae5043016d5b4ee3308b
Reviewed-on: https://go-review.googlesource.com/c/go/+/229768
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
The dup3 syscall is available since Linux 2.6.27. Fall back to dup2 (if
available) if dup3 returns ENOSYS.
This allows to omit the additional fcntl call to mark the dup'ed fd as
close-on-exec.
Change-Id: If318b593edd783f2aa988534c6062498e7119ddb
Reviewed-on: https://go-review.googlesource.com/c/go/+/220422
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use fcntl64Syscall in forkAndExecInChild1 to get fcntl64 on 32-bit Linux
systems.
Updates #36211
Change-Id: Id0e34359256beace970e72102fdace7a987ff2b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/212598
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing
"fork/exec ...: cannot allocate memory" failures from occuring when attempting
to execute commands from a Go process that has a large memory footprint.
Additionally, this should reduce the latency of fork/exec on linux/arm64.
With CLONE_VM the child process shares the same memory with the parent
process. On its own this would lead to conflicting use of the same
memory, so CLONE_VFORK is used to suspend the parent process until the
child releases the memory when switching to the new program binary
via the exec syscall. When the parent process continues to run, one
has to consider the changes to memory that the child process did,
namely the return address of the syscall function needs to be restored
from a register.
exec.Command() callers can start in a faster manner, as child process who
do exec commands job can be cloned faster via vfork than via fork on arm64.
The same problem was addressed on linux/amd64 via issue #5838.
Updates #31936
Contributed by Howard Zhang <howard.zhang@arm.com> and Bin Lu <bin.lu@arm.com>
Change-Id: Ia99d81d877f564ec60d19f17e596276836576eaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/189418
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
On unix if exec.Command() is given both ExtraFiles and Ctty, and the
Ctty file descriptor overlaps the range of FDs intended for the child,
then cmd.Start() the ioctl(fd,TIOCSCTTY) call fails with an
"inappropriate ioctl for device" error.
When child file descriptors overlap the new child's ctty the ctty will
be closed in the fd shuffle before the TIOCSCTTY. Thus TIOCSCTTY is
used on one of the ExtraFiles rather than the intended Ctty file. Thus
the error.
exec.Command() callers can workaround this by ensuring the Ctty fd is
larger than any ExtraFiles destined for the child.
Fix this by doing the ctty ioctl before the fd shuffle.
Test for this issue by modifying TestTerminalSignal to use more
ExtraFiles. The test fails on linux and freebsd without this change's
syscall/*.go changes. Other platforms (e.g. darwin, aix, solaris) have
the same fd shuffle logic, so the same fix is applied to them. However,
I was only able to test on linux (32 and 64 bit) and freebsd (64 bit).
Manual runs of the test in https://golang.org/issue/29458 start passing
with this patch:
Before:
% /tmp/src/go/bin/go run t
successfully ran child process with ParentExtraFileFdNum=5, ChildExtraFileFd=6, ParentPtyFd=7
panic: failed to run child process with ParentExtraFileFdNum=10, ChildExtraFileFd=11, ParentPtyFd=11: fork/exec /bin/true: inappropriate ioctl for device
After:
% /tmp/src/go/bin/go run t
successfully ran child process with ParentExtraFileFdNum=5, ChildExtraFileFd=6, ParentPtyFd=7
successfully ran child process with ParentExtraFileFdNum=10, ChildExtraFileFd=11, ParentPtyFd=11
Fixes#29458
Change-Id: I99513de7b6073c7eb855f1eeb4d1f9dc0454ef8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/178919
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing
"fork/exec ...: cannot allocate memory" failures from occuring when attempting
to execute commands from a Go process that has a large memory footprint.
Additionally, this should reduce the latency of fork/exec on these platforms.
The same problem was addressed on linux/amd64 via issue #5838.
Updates #31936
Change-Id: I7ae0fbbeaa29cab944a49a11272a380d497eb2d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/175697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before this CL, uid/gid mapping was always set up from the parent
process, which is a privileged operation.
When using unprivileged user namespaces, a process can modify its
uid/gid mapping after the unshare(2) call (but setting the uid/gid
mapping from another process is NOT possible).
Fixes#29789
Change-Id: I8c96a03f5da23fe80bbb83ef051ad89cf185d750
Reviewed-on: https://go-review.googlesource.com/c/go/+/158298
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
According to the prctl man page, each capability from the ambient set
must already be present in both the permitted and the inheritable
sets of the process.
exec_linux_test suggests configuring the capabilities in the parent
process. This doesn't look nice, because:
* Capabilities are a per-thread attribute, so we need to use
LockOSThread.
* Need to restore capabilities after creating a process.
* Doesn't work with user namespaces, because a process gets capabilities
when a namespace is created.
Fixes#23152
Change-Id: Iba23e530fc7b9f5182d602fe855f82218f354219
Reviewed-on: https://go-review.googlesource.com/c/go/+/156577
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Note that this particular combination of properties still fails (EPERM), but it
no longer hangs.
Updates #29789
Change-Id: I29b15b85a25a7acd7ae89ffc5fed074bcdfe0a12
Reviewed-on: https://go-review.googlesource.com/c/go/+/158297
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add the rawSyscallNoError wrapper function which is used for Linux
syscalls that don't return an error and convert all applicable
occurences of RawSyscall to use it instead.
Fixes#22924
Change-Id: Iff1eddb54573d459faa01471f10398b3d38528dd
Reviewed-on: https://go-review.googlesource.com/84485
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This will prevent any ptrace calls from getting trace output from the runtime
itself setting up after fork.
Fixes#21428.
Change-Id: I9d835bd5a8f404394eb6237679f2111a72e5bc17
Reviewed-on: https://go-review.googlesource.com/55811
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
This certainly won't get inlined right now, but in the spirit of
making this more robust, we have to disable inlining because inlining
would defeat the purpose of separating forkAndExecInChild1 into a
separate function.
Updates #20732.
Change-Id: I736c3f909cc42c5f5783740c2e19ba4827c7c2ec
Reviewed-on: https://go-review.googlesource.com/46174
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, CLONE_VFORK is used without much regard to the stack. This
is dangerous, because anything the child does to the stack is visible
to the parent. For example, if the compiler were to reuse named stack
slots (which it currently doesn't do), it would be easy for the child
running in the same stack frame as the parent to corrupt local
variables that the parent then depended on. We're not sure of anything
specific going wrong in this code right now, but it is at best a
ticking time bomb.
CLONE_VFORK can only safely be used if we ensure the child does not
execute in any of the active stack frames of the parent. This commit
implements this by arranging for the parent to return immediately from
the frame the child will operate in, and for the child to never return
to the frame the parent will operate in.
Fixes#20732.
Change-Id: Iad5b4ddc2b994c082bd278bfd52ef53bd38c037f
Reviewed-on: https://go-review.googlesource.com/46173
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Block all signals during a fork. In the parent process, after the
fork, restore the signal mask. In the child process, reset all
currently handled signals to the default handler, and then restore the
signal mask.
The effect of this is that the child will be operating using the same
signal regime as the program it is about to exec, as exec resets all
non-ignored signals to the default, and preserves the signal mask.
We do this so that in the case of a signal sent to the process group,
the child process will not try to run a signal handler while in the
precarious state after a fork.
Fixes#18600.
Change-Id: I9f39aaa3884035908d687ee323c975f349d5faaa
Reviewed-on: https://go-review.googlesource.com/45471
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The current implementation of forkAndExecInChild for Linux does not allow
spawned processes steal the controlling terminal from a different session
group. This patch passes 1 as the argument to TIOCSCTTY in order to allow
spawned processes steal controlling terminals.
Fixes#20454
Change-Id: I171b8981509d648b07f89bddc1e9d45cb70e00e6
Reviewed-on: https://go-review.googlesource.com/44343
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
When unshare specifies a new namespace, the syscall
package changes / to make namespace changes private.
If a chroot is specified, the unshare must be done first.
If the chroot is done first then the unshare will
not specify the correct /.
A new test is included which test combining chroot
and CLONE_NEWNS; it fails without the patch and works with
it.
Fixes#20103
Change-Id: I86022803c784bd418a30383321f3d64103d95c62
Reviewed-on: https://go-review.googlesource.com/41626
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In some newer Linux distros, systemd forces
all mount namespaces to be shared, starting
at /. This disables the CLONE_NEWNS
flag in unshare(2) and clone(2).
While this problem is most commonly seen
on systems with systemd, it can happen anywhere,
due to how Linux namespaces now work.
Hence, to create a private mount namespace,
it is not sufficient to just set
CLONE_NEWS; you have to call mount(2) to change
the behavior of namespaces, i.e.
mount("none", "/", NULL, MS_REC|MS_PRIVATE, NULL)
This is tested and working and we can now correctly
start child process with private namespaces on Linux
distros that use systemd.
The new test works correctly on Ubuntu 16.04.2 LTS.
It fails if I comment out the new Mount, and
succeeds otherwise. In each case it correctly
cleans up after itself.
Fixes#19661
Change-Id: I52240b59628e3772b529d9bbef7166606b0c157d
Reviewed-on: https://go-review.googlesource.com/38471
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>