This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients Billy McCulloch, JDM, Paul Doom, earonesty, eryksun, georg.brandl, ncoghlan, paul.moore, python-dev, rocco.matano, rupole, serhiy.storchaka, steve.dower, takluyver, tim.golden, zach.ware
Date 2019-07-02.00:24:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1562027070.78.0.993824883955.issue22107@roundup.psfhosted.org>
In-reply-to
Content
CanAccessFolder is incomplete for the following reasons:

(1) It doesn't account for SeBackupPrivilege (read and execute access) and SeRestorePrivilege (write and delete access). If a create or open call requests backup semantics, these two privileges are checked by the I/O Manager in order to grant access before the request is sent to the filesystem device stack. That said, our os.open() call doesn't use O_OBTAIN_DIR (0x2000), an undocumented flag that allows opening a directory by requesting backup semantics. If it did use this undocumented flag, there would actually be no problem to solve since we would get FileExistsError instead of PermissionError.

(2) It doesn't check the parent directory in case FILE_READ_ATTRIBUTES access (required for GENERIC_READ) or DELETE access (required for GENERIC_ALL) are either not granted or denied to the user for the target directory. These rights are granted by NT filesystem policy if FILE_READ_DATA and FILE_DELETE_CHILD access are granted to the parent directory, respectively. This is a general concern that's not relevant here since we only need to check the directory for write access (i.e. FILE_ADD_FILE).

(3) It doesn't get the LABEL_SECURITY_INFORMATION from the file security, in order to check for no-read-up, no-write-up, and no-execute-up mandatory access. Adding files to a directory is disallowed if its mandatory label denies write-up access and its integrity level is higher than the caller's (e.g. the caller is a standard user at medium integrity level, and the directory is at high or system integrity level).

(4) It doesn't check effective access via OpenThreadToken, in case the thread is impersonating.

(5) It cannot take into account access granted or denied by filesystem filter drivers such as antimalware programs. For this, we need to actually try to open the directory with the requested access via CreateFile. We're granted the required access if CreateFile succeeds, or if it fails with a sharing violation (i.e. winerror 32). A sharing violation isn't an issue since in practice adding a file to a directory is internal to a filesystem; it doesn't count against shared data access.
History
Date User Action Args
2019-07-02 00:24:30eryksunsetrecipients: + eryksun, georg.brandl, paul.moore, ncoghlan, rupole, tim.golden, python-dev, takluyver, zach.ware, serhiy.storchaka, steve.dower, rocco.matano, Billy McCulloch, Paul Doom, earonesty, JDM
2019-07-02 00:24:30eryksunsetmessageid: <1562027070.78.0.993824883955.issue22107@roundup.psfhosted.org>
2019-07-02 00:24:30eryksunlinkissue22107 messages
2019-07-02 00:24:30eryksuncreate