os: consider mapping Unix permissions bits to Windows ACLs #70524
Labels
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
The
os.FileMode
/io/fs.FileMode
type represents a file's "mode and permission bits".Permission bits are a Unix concept.
FileMode
exposes these bits directly: "The nine least-significant bits are the standard Unix rwxrwxrwx permissions." (TheFileMode
documentation doesn't even bother to specify which bit is which, assuming that this is common knowledge.)On Windows, the
os
package translates the permission bits to theFILE_ATTRIBUTE_READONLY
attribute:FILE_ATTRIBUTE_READONLY
if the bit 0o200 (user-writable) is not set.FILE_ATTRIBUTE_READONLY
is set, 0o666 otherwise.The
os
package does not attempt to distinguish between the user/group/other bits. It is not possible to create a file readable only by the current user.os.CreateTemp
is documented as creating files with mode 0o600; while technically accurate (the best kind of accurate!), this is somewhat misleading on Windows because the file will be world read/writable.A similar issue with Python temporary files was assigned CVE-2024-4030. After some discussion, we're inclined to say that
os.CreateTemp
's current behavior is not a vulnerability since theos
package's lack of support for Windows permissions is well-known andCreateTemp
does indeed behave according to its documentation in that light. But it's certainly unfortunate.This issue is to consider the possibility of mapping Unix permission bits to Windows ACLs in the
os
package. There are well-known security identifiers (SIDs) that translate fairly closely to the Unix concepts of user/group/other:SECURITY_CREATOR_OWNER_RID
,SECURITY_CREATOR_GROUP_RID
, andSECURITY_WORLD_RID
. The OS package could set an ACL on new files using these SIDs, and possibly translate simple ACLs to Unix permissions when returning aFileMode
.Making this change has the risk of breaking existing programs that depend on the current behavior. We'd definitely want a GODEBUG to revert to the old behavior.
The text was updated successfully, but these errors were encountered: