Necessary to move PathError to io/fs.
For #41190.
Change-Id: I05e87675f38a22f0570d4366b751b6169f7a1b13
Reviewed-on: https://go-review.googlesource.com/c/go/+/243900
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Builds upon the changes from #32000 which supported sourcing environment
variables for a new process from the environment of a Windows user token
when supplied.
But due to the logic of os/exec, the Env field of a process was
always non-nil when it reached that change.
This change moves the logic up to os/exec, specifically when
os.ProcAttr is being built for the os.StartProcess call, this
ensures that if a user token has been supplied and no Env slice has
been provided on the command it will be sourced from the user's
environment.
If no token is provided, or the program is compiled for any other
platform than Windows, the default environment will be sourced from
syscall.Environ().
Fixes#35314
Change-Id: I4c1722e90b91945eb6980d5c5928183269b50487
GitHub-Last-Rev: 32216b7291
GitHub-Pull-Request: golang/go#37402
Reviewed-on: https://go-review.googlesource.com/c/go/+/220587
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
You were a useful port and you've served your purpose.
Thanks for all the play.
A subsequent CL will remove amd64p32 (including assembly files and
toolchain bits) and remaining bits. The amd64p32 removal will be
separated into its own CL in case we want to support the Linux x32 ABI
in the future and want our old amd64p32 support as a starting point.
Updates #30439
Change-Id: Ia3a0c7d49804adc87bf52a4dea7e3d3007f2b1cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/199499
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is CVE-2019-11888.
Previously, passing a nil environment but a non-nil token would result
in the new potentially unprivileged process inheriting the parent
potentially privileged environment, or would result in the new
potentially privileged process inheriting the parent potentially
unprivileged environment. Either way, it's bad. In the former case, it's
an infoleak. In the latter case, it's a possible EoP, since things like
PATH could be overwritten.
Not specifying an environment currently means, "use the existing
environment". This commit amends the behavior to be, "use the existing
environment of the token the process is being created for." The behavior
therefore stays the same when creating processes without specifying a
token. And it does the correct thing when creating processes when
specifying a token.
Fixes#32000
Change-Id: Ia57f6e89b97bdbaf7274d6a89c1d9948b6d40ef5
Reviewed-on: https://go-review.googlesource.com/c/go/+/176619
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
When Stdin, Stdout, and Stderr are nil, there are no goroutines to keep
track of, so we don't need a channel.
And in startProcess, preallocate the right size for sysattr.Files,
saving a bit of space and a couple of slice growth allocs.
name old time/op new time/op delta
ExecHostname-8 419µs ± 0% 417µs ± 1% ~ (p=0.093 n=6+6)
name old alloc/op new alloc/op delta
ExecHostname-8 6.40kB ± 0% 6.28kB ± 0% -1.86% (p=0.002 n=6+6)
name old allocs/op new allocs/op delta
ExecHostname-8 34.0 ± 0% 31.0 ± 0% -8.82% (p=0.002 n=6+6)
Change-Id: Ic1d617f29e9c6431cdcadc7f9bb992750a6d5f48
Reviewed-on: https://go-review.googlesource.com/c/164801
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I was confused by the juxtaposition of os.Interrupt docs, which are
"guaranteed to exist on all platforms" in one sentence and then
"not implemented" in the next sentence. Reading the code reveals
"not implemented" refers specifically to the implementation of
os.Process.Signal on Windows, not to the os.Interrupt variable itself.
Reword the doc to make this distinction clearer.
Fixes#27854.
Change-Id: I5fe7cddea61fa1954cef2006dc51b8fa8ece4d6e
Reviewed-on: https://go-review.googlesource.com/c/137336
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This commit adds the js/wasm architecture to the os package.
Access to the actual file system is supported through Node.js.
Updates #18892
Change-Id: I6fa642fb294ca020b2c545649d4324d981aa0408
Reviewed-on: https://go-review.googlesource.com/109977
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Note that Interrupt will compile but not work on Windows.
Fixes#22454
Change-Id: If011c32211f4bb45d458317e113b9794d5b4a4b1
Reviewed-on: https://go-review.googlesource.com/81035
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Remove use of itod on posix systems and replace with call to itoa.
Build and use same itoa function on all systems.
Fix infinite recursion in iota function for the case -1<<63.
Change-Id: I89d7e742383c5c4aeef8780501c78a3e1af87a6f
Reviewed-on: https://go-review.googlesource.com/2213
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
