-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
syscall: Windows does not respect permission bits passed to Open #35033
Comments
Suggested issue title change: "syscall: Windows does not respect permission bits passed to Open" |
Change https://golang.org/cl/202439 mentions this issue: |
Change https://golang.org/cl/202440 mentions this issue: |
Thanks! I wasn't sure what the root cause would turn out to be, so I didn't want to make assumptions in the initial title. 😉 |
Chmod toggles the FILE_ATTRIBUTES_READONLY flag depending on the permission bits. That's a bit odd but I guess some compromises were made at some point and this is what was chosen to map to a Unix concept that Windows doesn't really have in the same way. That's fine. However, the logic used in Chmod was forgotten from Open, which then manifested itself in various places, most recently, go modules' read-only behavior. This corresonds with the syscall CL 202439. Updates golang/go#35033 Change-Id: Id8e74c5205057a74a35eda213516780b79a2aed2 Reviewed-on: https://go-review.googlesource.com/c/sys/+/202440 Run-TryBot: Jason A. Donenfeld <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Bryan C. Mills <[email protected]> Reviewed-by: Alex Brainman <[email protected]>
Change https://golang.org/cl/223957 mentions this issue: |
In the fix for golang/go#35033 Go started creating read-only files on Windows when no read permission bit was requested in the OpenFile call. This was not documented in the release notes (but see https://go-review.googlesource.com/c/go/+/223957/). Deal with the immediate issue by adding owner-read and owner-write permissions in our WriteFile which creates the file. Also add a workaround for the fact that previous version of Fleetspeak have left behind read-only files - simply clear the read-only attribute if the file already exists.
For #35033 Change-Id: Ie15353322d5cfe7320199103ad9543fb89a842ed Reviewed-on: https://go-review.googlesource.com/c/go/+/223957 Reviewed-by: Brendan Jackman <[email protected]> Reviewed-by: Bryan C. Mills <[email protected]>
Change https://golang.org/cl/223962 mentions this issue: |
…ermissions For #35033 For #36878 Change-Id: Ie15353322d5cfe7320199103ad9543fb89a842ed Reviewed-on: https://go-review.googlesource.com/c/go/+/223957 Reviewed-by: Brendan Jackman <[email protected]> Reviewed-by: Bryan C. Mills <[email protected]> (cherry picked from commit e39de05) Reviewed-on: https://go-review.googlesource.com/c/go/+/223962 Reviewed-by: Dmitri Shuralyov <[email protected]>
In the course of testing #31481, I found the following failure on the
windows
builders at patch set 3 (https://storage.googleapis.com/go-build-log/096e97bd/windows-386-2008_7b478c28.log):This suggests that either the
root
condition inTestScript
is failing to detect a user acting in some sort of root-like role on Windows, or else we are failing to mark the contents of the module cache read-only on Windows.CC @jayconrod @alexbrainman @zx2c4
The text was updated successfully, but these errors were encountered: