x/sys/windows: GetCurrentProcessToken() not working on Windows 7 SP1

[kmahyyg]

What version of Go are you using (go version)?

$ go version
go version go1.19.3 windows/amd64

Does this issue reproduce with the latest release?

Yes, I'm currently running latest release.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOARCH=amd64
set GOVERSION=go1.19.3
set GCCGO=gccgo
set GOAMD64=v1
set GOOS=windows

What did you do?

Under Windows 10 Build 19044, CGO disabled, compile a program, code here: https://go.dev/play/p/LjfMdT6mTHZ

What did you expect to see?

Run on Windows 10 (which I compiled the binary): working as intended
Run on Windows 7 SP1 (Build 7601): working as intended

What did you see instead?

Run on Windows 10 (which I compiled the binary): working as intended
Run on Windows 7 SP1 (Build 7601, Version 6.1.7601): Error message: The handle is invalid.

I confirmed that I've closed all the antivirus which might affect the program running, to reproduce the bug, use "-fakeToken=true" as cmdline param.

[thanm]

Relevant: #57003

[mknyszek]

CC @golang/windows

[kmahyyg]

If #57003 #57004 are accepted, this issue should be closed directly. I've migrated to Windows Server 2022 now, but there's still a lot of Windows 7 in my company, I am really worrying about their assets. XD

[alexbrainman]

I read code at https://go.dev/play/p/LjfMdT6mTHZ and the error can be returned on line 44 or 48. It would help to write repro code in a way that is always obvious where the problem is.

I suspect this code might fail for many different reasons other than been run on Windows 7. But I am not Windows security expert. So I could be wrong.

@kmahyyg you will have better chance to get help with this, if you post your question somewhere where Windows developers are. Perhaps https://stackoverflow.com ?

Alex

[kmahyyg]

@alexbrainman

and the error can be returned on line 44 or 48.

Just add a line number in error message when print out. Now it's L44. Check pointer in memory using debugger, you'll see more.

I mostly wrote these code using Windows native CPP, they are always working in CPP, But I don't know why these functions in golang library are written in this way.

[alexbrainman]

... I mostly wrote these code using Windows native CPP, they are always working in CPP, But I don't know why these functions in golang library are written in this way.

If you can reproduce this problem with C program, you can just compare your C and Go programs and see what is different. You can remove bits from your programs until it is obvious where the problem is.

Alex

[kmahyyg]

The problem here is why your library implements the function in this way which lead to fault. Not my code. I just give an example and say I met a situation that something went wrong. And trying to tell u there's an issue.

[kmahyyg]

Ouch, and also, Windows 7 reaches its EOL in a few days. Let's just throw it away. (even a lot of Windows 7 machines is running in Production)

[kmahyyg]

@alexbrainman Token(^uintptr(4 - 1)) makes me really confused, though.

https://cs.opensource.google/go/x/sys/+/refs/tags/v0.3.0:windows/security_windows.go;l=668

//sys	OpenProcessToken(process Handle, access uint32, token *Token) (err error) = advapi32.OpenProcessToken

type Token Handle

// OpenCurrentProcessToken opens an access token associated with current
// process with TOKEN_QUERY access. It is a real token that needs to be closed.
//
// Deprecated: Explicitly call OpenProcessToken(CurrentProcess(), ...)
// with the desired access instead, or use GetCurrentProcessToken for a
// TOKEN_QUERY token.
func OpenCurrentProcessToken() (Token, error) {
	var token Token
	err := OpenProcessToken(CurrentProcess(), TOKEN_QUERY, &token)
	return token, err
}

// GetCurrentProcessToken returns the access token associated with
// the current process. It is a pseudo token that does not need
// to be closed.
func GetCurrentProcessToken() Token {
	return Token(^uintptr(4 - 1))
}