gh-118486: Support mkdir(mode=0o700) on Windows #118488
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
eryksun
reviewed
May 1, 2024
| data->ea[0].grfInheritance = SUB_CONTAINERS_AND_OBJECTS_INHERIT; | ||
| data->ea[0].Trustee.TrusteeForm = TRUSTEE_IS_NAME; | ||
| data->ea[0].Trustee.TrusteeType = TRUSTEE_IS_ALIAS; | ||
| data->ea[0].Trustee.ptstrName = L"CURRENT_USER"; |
There was a problem hiding this comment.
What about the security issue for an elevated administrator? Say you're an elevated administrator with the account name "SpamAdmin". If you create a directory that you should only be able to access when elevated (e.g. in another user's profile), then no permissions should be granted to the "SpamAdmin" account, which would allow access even when not elevated.
Since administrator access tokens use the "Administrators" group as the owner of new objects, a generic approach would be to assign full control to the "OWNER_RIGHTS" SID (S-1-3-4)1 instead of the current user. Otherwise the implementation has to omit the entry for the current user if the user is an elevated administrator.
Footnotes
-
Note there are significant differences in what ownership means and how it's handled on POSIX vs Windows. On POSIX, the owner must be a user, not a group, and the owner permissions apply exactly to the owner, even if an ACL is present. On Windows, the owner can be a group. Also, access is cumulative across the mandatory label and entries in the discretionary ACL. A user that's an effective owner could match other allow or deny entries in the discretionary ACL, and thus have a different set of rights than the explicit owner-rights. This isn't a problem given the simple ACL that's being set for
0o700. ↩
There was a problem hiding this comment.
That's interesting, I hadn't come across OWNER_RIGHTS before (seems it's newer than the rest). It doesn't appear to be a supported alias, unfortunately.
I think it's good to know about, but as you say in the footnote, CURRENT_USER is closer to emulating POSIX semantics (for better or worse). If we/someone produce a library with full-featured ACL support, being able to arrange that nuance would be worth supporting, but I think this sufficiently improves our "best effort" (by imitating the ACLs that would be applied to any directory in the user profile, but for directories outside of the profile as well).
There was a problem hiding this comment.
If a user wouldn't be allowed to create the directory without elevating, they shouldn't have access to it when not elevated. That's why the owner is set to the Administrators group in this case, for inherited "CREATOR_OWNER" permissions. Since we're bypassing inheritance, the onus is on us to make this secure. That's addressed by omitting the "CURRENT_USER" entry if the current user is an elevated administrator. Or by using "OWNER_RIGHTS".
That's interesting, I hadn't come across OWNER_RIGHTS before (seems it's newer than the rest). It doesn't appear to be a supported alias, unfortunately.
It's been around for a long time; I think since Windows 7 (2008). One would use CreateWellKnownSid(WinCreatorOwnerRightsSid, ...) and set an entry for TRUSTEE_IS_SID.
|
GH-118740 is a backport of this pull request to the 3.10 branch. |
|
GH-118738 is a backport of this pull request to the 3.12 branch. |
|
GH-118739 is a backport of this pull request to the 3.11 branch. |
|
GH-118741 is a backport of this pull request to the 3.9 branch. |
|
GH-118742 is a backport of this pull request to the 3.8 branch. |
SonicField
pushed a commit
to SonicField/cpython
that referenced
this pull request
May 8, 2024
zooba
added a commit
that referenced
this pull request
May 9, 2024
ambv
pushed a commit
that referenced
this pull request
May 24, 2024
ambv
added a commit
that referenced
this pull request
May 24, 2024
ambv
added a commit
that referenced
this pull request
May 24, 2024
ambv
added a commit
that referenced
this pull request
May 24, 2024
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
mkdir(mode=0o700)to work on Windows #118486📚 Documentation preview 📚: https://cpython-previews--118488.org.readthedocs.build/