https://go.dev/cl/614296 includes a simple test of file permissions:
- os.WriteFile a file with 0o444 permissions (read-only).
- os.WriteFile the file again. This should fail, since the file is read-only.
This test passes for me locally. It fails on linux-386 and linux-amd64 trybots. (It passes on wasip1 builders, ignore that, wasip1 doesn't support file permissions.)
Confusingly, it passes on linux gomotes. I can't replicate the trybot failure anywhere.
Logging in the test confirms that the file is being created with mode 0444. We're still able to write to it.
I have no idea what's going on here; I assume it's some trybot weirdness rather than our bug, but I don't know what might cause it.
Comment From: cagedmantis
cc rsc @ianlancetaylor @bradfitz @griesemer
Comment From: ianlancetaylor
Is it possible that the trybot is running the tests as root?
I'm checking that possibility in https://go.dev/cl/614377.
Comment From: ianlancetaylor
Yes, that is why.
I think these tests will have to be skipped for root. We have similar skips in, for example, TestRemoveAllButReadOnlyAndPathError.
Comment From: dmitshur
It's likely related that linux-386 and linux-amd64 builders are configured to run with a no-network check:
https://cs.opensource.google/go/x/build/+/luci-config:main.star;l=527-532;drc=c29a1893e55d9ac317ea49eb6a4479b48521662d
Whose current implementation uses --map-root-user in the unshare call, see here.
If so, the key to reproducing locally is to run the test in the same way:
unshare --net --map-root-user -- \
sh -c 'ip link set dev lo up && go test -run=^TestCreateFilePermissions$'
Comment From: dmitshur
In build 8736249311634815793 (a shard of a real linux-amd64 build on CL 614296, whose no_network property is true) TestCreateFilePermissions fails. In build 8736232595984980273 (a shadow build with identical inputs as the build above, except it has no_network property overridden to false), TestCreateFilePermissions passes with:
=== RUN TestCreateFilePermissions
os_test.go:2948: file mode = 444
--- PASS: TestCreateFilePermissions (0.00s)
So it's confirmed as the relevant variable.
Shadow build launch command details
$ led get-build -real-build 8736249311634815793 | led edit -pa no_network=false | led launch
[I 2024-09-20 19:52:52] getting build definition
[I 2024-09-20 19:52:53] Launching the led job as a real build
[I 2024-09-20 19:52:53] LUCI UI: https://ci.chromium.org/b/8736232595984980273
Comment From: neild
I think these tests will have to be skipped for root.
I had managed to completely forget that root gets to ignore file modes. Thanks for a mystery solved!