Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/rand: Read fails for non-interactive processes on Windows #7940

alotabits opened this issue May 5, 2014 · 6 comments

crypto/rand: Read fails for non-interactive processes on Windows #7940

alotabits opened this issue May 5, 2014 · 6 comments
OS-Windows Suggested


Copy link

@alotabits alotabits commented May 5, 2014

What does 'go version' print?

go version go1.2 windows/amd64

What steps reproduce the problem?

1. Create a simple cgi executable containing the code at
2. Create an application in IIS 7.5 to run this as a cgi handler under DefaultAppPool,
with CGI/Impersonate User=False, and the web.config included at the link above (or
3. Visit URL of cgi handler

What happened?

Received "CryptAcquireContext: Access is denied."

What should have happened instead?

Receive random gibberish

Please provide any additional information below.

Based on a limited understanding of the Windows cryto APIs from this reference page:

I think adding the CRYPT_MACHINE_KEYSET flag to src/pkg/crypto/rand/rand_windows.go:30
might resolve the issue. I do not know what side-effects this might have.
Copy link

@ianlancetaylor ianlancetaylor commented May 5, 2014

Comment 1:

Labels changed: added repo-main, release-go1.3maybe, os-windows.

Copy link

@alexbrainman alexbrainman commented May 6, 2014

Comment 2:

I agree. The cgi executable would be started by IIS, and would be running under "Local
System" (or similar) system account. So it wouldn't have access to any "user profile".
For these examples, CRYPT_MACHINE_KEYSET is used because the security context in which
the application is running does not have access to a user profile.
I made this change:
diff --git a/src/pkg/crypto/rand/rand_windows.go b/src/pkg/crypto/rand/rand_windows.go
--- a/src/pkg/crypto/rand/rand_windows.go
+++ b/src/pkg/crypto/rand/rand_windows.go
@@ -27,7 +27,7 @@
    if r.prov == 0 {
        const provType = syscall.PROV_RSA_FULL
-       const flags = syscall.CRYPT_VERIFYCONTEXT | syscall.CRYPT_SILENT
+       const flags = syscall.CRYPT_VERIFYCONTEXT | syscall.CRYPT_SILENT |
        err := syscall.CryptAcquireContext(&r.prov, nil, nil, provType, flags)
        if err != nil {
and all tests still pass. (gloume, can you please see if it helps your case?)
But I am not convinced it is safe to simply add syscall.CRYPT_MACHINE_KEYSET in general
case. See syscall.CRYPT_MACHINE_KEYSET description in for
details. Perhaps I'm mistaken.
Alternatively, we can try and include syscall.CRYPT_MACHINE_KEYSET selectively. We can
detect, if we're running as service like so, and include
syscall.CRYPT_MACHINE_KEYSET only then. But it complicates things for everyone.
Looking for suggestions.

Copy link

@alotabits alotabits commented May 6, 2014

Comment 3:

Unfortunately, it appears that this simple flag does not fix the issue for
Assuming there is some other combination of magic flags that will fix the
issue, could we create an init function in rand_windows.go (or a shared
platform-specific location) that is similar to IsAnInteractiveSession and
sets a boolean for the whole process? That would make for an easy check in
Read(), but it assumes that a process can't transition from interactive to

Copy link

@alexbrainman alexbrainman commented May 7, 2014

Comment 4:

> ... Unfortunately, it appears that this simple flag does not fix the issue for me.
Then I don't know what the problem is. Perhaps it wants different flag. Try reading
windows refs and use different flags. I don't have time to play with this now. Maybe
later. Sorry.

Copy link

@rsc rsc commented May 9, 2014

Comment 5:

Labels changed: added release-none, suggested, removed release-go1.3maybe.

Status changed to Accepted.

@alotabits alotabits added accepted Suggested labels May 9, 2014
Copy link

@mattn mattn commented Jan 16, 2015

I tried this but can't reproduce.

@rsc rsc removed the os-windows label Apr 10, 2015
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
OS-Windows Suggested
None yet

No branches or pull requests

5 participants