delta/go-git.git/src/syscall, branch dev.debug

syscall: update check for UserNS support for centos 7

2017-07-17T18:18:08+00:00

Fixes #20796
Fixes #16283

Change-Id: Ib11992fbd2bc1fbb3b14ae5a6bf0da2e4c12f641
Reviewed-on: https://go-review.googlesource.com/49311
Reviewed-by: Brad Fitzpatrick 
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

syscall: skip TestUnshare on Linux upon permission error

2017-07-14T21:05:21+00:00

Fixes #17206

Change-Id: Id0ebc3a55ea1c5f52608decffee04c8398a8774b
Reviewed-on: https://go-review.googlesource.com/48571
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

syscall: use correct go binary in test

2017-07-12T23:39:39+00:00

Usually this test is skipped (on builders and when not root), so
people are unlikely to see this error.

Updates #19296

Change-Id: I3acb81260034dad8776c305f83d7cbac4b718e75
Reviewed-on: https://go-review.googlesource.com/48191
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

syscall: add AmbientCaps to linux SysProcAttr

2017-06-28T22:59:47+00:00

Fixes #19713

Change-Id: Id1ca61b35bca2a4bea23dd64c7fb001a3a14fd88
Reviewed-on: https://go-review.googlesource.com/43512
Reviewed-by: Ian Lance Taylor

syscall: fix Exec on solaris

2017-06-28T19:02:05+00:00

The test added for issue #18146 exposed a long-existing bug in the
Solaris port; notably, that syscall.Exec uses RawSyscall -- which is not
actually functional for the Solaris port (intentionally) and only exists
as a placebo to satisfy build requirements.

Call syscall.execve instead for Solaris.

Fixes #20832

Change-Id: I327d863f4bbbbbb6e5ecf66b82152c4030825d09
Reviewed-on: https://go-review.googlesource.com/47032
Run-TryBot: Shawn Walker-Salas 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor 
Reviewed-by: Brad Fitzpatrick

runtime, syscall: workaround for bug in Linux's execve

2017-06-20T23:53:17+00:00

Linux's execve has (at the time of writing, and since v2.6.30) a bug when it ran
concurrently with clone, in that it would fail to set up some datastructures if
the thread count before and after some steps differed. This is described better
and in more detail by Colin King in Launchpad¹ and kernel² bugs. When a program
written in Go runtime.Exec's a setuid binary, this issue may cause the resulting
process to not have the expected uid. This patch works around the issue by using
a mutex to serialize exec and clone.

1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819
2. https://bugzilla.kernel.org/show_bug.cgi?id=195453

Fixes #19546

Change-Id: I126e87d1d9ce3be5ea4ec9c7ffe13f92e087903d
Reviewed-on: https://go-review.googlesource.com/43713
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gobot Gobot

syscall: mark forkAndExecInChild1 noinline

2017-06-20T21:54:19+00:00

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 
TryBot-Result: Gobot Gobot 
Reviewed-by: Brad Fitzpatrick

syscall: use CLONE_VFORK safely

2017-06-20T19:55:45+00:00

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 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

runtime, syscall: reset signal handlers to default in child

2017-06-14T14:00:56+00:00

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 
TryBot-Result: Gobot Gobot 
Reviewed-by: Austin Clements

syscall: make windows Exit call runtime.exit

2017-06-08T23:28:28+00:00

Both runtime.exit and syscall.Exit call Windows ExitProcess.
But recently (CL 34616) runtime.exit was changed to ignore
Windows CreateThread errors if ExitProcess is called.

This CL adjusts syscall.Exit to do the same.

Fixes #18253 (maybe)

Change-Id: I6496c31b01e7c7d73b69c0b2ae33ed7fbe06736b
Reviewed-on: https://go-review.googlesource.com/45115
TryBot-Result: Gobot Gobot 
Reviewed-by: Rob Pike 
Reviewed-by: Austin Clements