Use 0644 instead of 0666 for file mode in openFile#87
Conversation
On systems with a permissive umask (e.g. Docker containers), 0666 produces world-writable files. 0644 is the conventional permission for non-executable source files. Closes #82
Stat the file before opening it, then explicitly Chmod it back to the original mode after writing. This makes permission preservation robust and explicit, rather than relying on the implicit behaviour of the OS when writing to an already-open file handle. The mode argument to os.OpenFile is dropped (set to 0) since it has no effect when O_CREATE is absent. The Chmod call is now the authoritative place where the file's mode is handled.
os.OpenFile without O_CREATE never modifies an existing file's permissions — WriteAt and Truncate don't either — so the mode argument of 0666 was both misleading and a no-op. Passing 0 makes it explicit that no permission bits are being set here.
|
After further analysis this fix is not needed.
The only change that makes sense here is replacing |
1 participant
Summary
Change the permission mode passed to
os.OpenFilein theopenFilehelper from0666(world-writable) to0644(owner read/write, group and world read-only).On systems with a permissive umask — common in Docker containers and some CI runners —
0666leaves files rewritten byembedmd -wworld-writable, allowing any local user to tamper with them.0644is the conventional mode for non-executable source and documentation files.A
TestOpenFilePermissionstest is added to verify the file opened by the productionos.OpenFilecall has no group/world write bits set.Test plan
TestOpenFilePermissions— stat a real temp file after opening it and assertmode & 0022 == 0go test ./...)Closes #82