#7506 closed Bugs (fixed)
unique_path Fails on Windows for Temporary User Profiles
| Reported by: | Owned by: | Beman Dawes | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | filesystem |
| Version: | Boost 1.51.0 | Severity: | Problem |
| Keywords: | Cc: |
Description
boost::filesystem::unique_path is failing on Windows if the user has a temporary (read-only) profile (e.g. guest account). I have tracked the problem down to a failure in libs/filesystem/src/unique_path.cpp when it calls CryptAcquireContextW.
CryptAcquireContextW is failing with the arguments used. It appears that this is by design, for read-only profiles. See http://blogs.msdn.com/b/alejacma/archive/2007/10/23/rsacryptoserviceprovider-fails-when-used-with-mandatory-profiles.aspx for some background information.
I have modified the dwFlags argument of both calls to CryptAcquireContextW, adding CRYPT_VERIFYCONTEXT | CRYPT_SILENT and it is now working for me. I'm no expert on the Win32 crypto API so I'm not sure if this is a valid solution in all contexts.
Attachments (1)
Change History (9)
by , 9 years ago
| Attachment: | 001-unique_path_windows.patch added |
|---|
comment:1 by , 9 years ago
comment:2 by , 9 years ago
We have had a similar issue with our software on one user's machine.
I tracked it down to CryptAcquireContextW failing with NTE_BAD_KEY_STATE (0x8009000B) - 'Key not valid for use in specified state'.
I will test if the patch fixes their issue too.
comment:3 by , 9 years ago
Regarding the NTE_BAD_KEY_STATE problem i mentioned above, this patch also resolves the issue.
+1 for integrating the patch into boost. ;)
comment:4 by , 8 years ago
The documentation for CryptAcquireContext (which I apparently cannot link to without the post being considered spam) also says that CRYPT_VERIFYCONTEXT should be passed in the flags when doing any operation that doesn't require access to persisted private keys for performance reasons, which is the case here.
comment:5 by , 8 years ago
Is there anything preventing the integration of the provided patch to fix this bug? Is there any way to bump up its priority? Anything I can do to help?
Thanks!
comment:7 by , 7 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Thanks to the submitter and all the commenters, and also Sebastian Redl for including this fix in his larger pull request #15.
--Beman
comment:8 by , 6 years ago
The pull request mentioned above is available here and was first included in Boost 1.60
Thanks for fixing that :)
Cedric
This issue also happens when running application in low integrity level: see msdn "Designing Applications to Run at a Low Integrity Level"