Creating and deleting users is tricky to get right, and it's not
something we want to do on a developer machine. This change skips the
tests that create users when not running on a Go builder.
This will fix#70396, although I still don't understand why the test
user couldn't be recreated.
Fixes#70396
Change-Id: Ie7004dc209f94e72152c7d6bd8ec95cc12c79757
Reviewed-on: https://go-review.googlesource.com/c/go/+/627877
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: I9aa34951f2005c204aafd9da74e78c033c9b64ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/629315
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Built-in service user accounts should be treated as special cases
of well-known groups and allowed in user.Lookup and user.LookupId.
Namely, these accounts are:
- NT AUTHORITY\SYSTEM (S-1-5-18)
- NT AUTHORITY\LOCAL SERVICE (S-1-5-19)
- NT AUTHORITY\NETWORK SERVICE (S-1-5-20)
See https://learn.microsoft.com/en-us/windows/win32/services/service-user-accounts.
Note that #49509 also mentions S-1-5-17 (NT AUTHORITY\IUSR) as
another well-known group that should be treated as a user. I haven't
found any documentation supporting this claim, and it is not an account
that is used usually, so I'm not adding it for now.
This CL is heavily based on CL 452497.
Fixes#49509
Change-Id: I6e204ddfb4ed0c01b4503001cf284602531e4a88
Reviewed-on: https://go-review.googlesource.com/c/go/+/626255
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
On Windows, the User.GroupIds currently errors out if the user has no
groups. This is incorrect, as the user may not be a member of any groups
as demonstrated by the new TestGroupIdsTestUser test.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-arm64
Change-Id: I436aa6214f2b98ef98dfb6064caec3d682b3f3d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/606675
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
As some callers don't have a testing context, modify testenv.Executable
to accept nil (similar to how testenv.GOROOT works).
Change-Id: I39112a7869933785a26b5cb6520055b3cc42b847
Reviewed-on: https://go-review.googlesource.com/c/go/+/609835
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The syscall.OpenCurrentProcessToken call in user.Current fails
when called from an impersonated thread, as the process token is
normally in that case.
This change ensures that the current thread is not impersonated
when calling OpenCurrentProcessToken, and then restores the
impersonation state, if any.
Fixes#68647
Change-Id: I3197535dd8355d21029a42f7aa3936d8fb021202
Reviewed-on: https://go-review.googlesource.com/c/go/+/602415
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
qmuntal
Ian Lance Taylor
Kir Kolyshkin