Eryk Sun <eryk...@gmail.com> added the comment:
> Anyone else know of any possible causes for this?
The installer service runs as SYSTEM, with an access token at system integrity
level that has full privileges and the administrators group enabled. Nothing in
the file security should prevent the service from opening
"%APPDATA%\Microsoft\Installer" with WRITE_DAC [1] and WRITE_OWNER [2] access,
assuming it uses backup semantics with the restore privilege enabled, but
apparently it doesn't.
I was able to reproduce the error dialog by changing the owner of the
"Installer" folder to the current user and removing the two DACL entries that
grant access to Administrators and SYSTEM. I then restored normal operation by
changing the owner of the folder back to the Administrators group and adding
the full-control DACL entries for Administrators (BA) and SYSTEM (SY):
takeown /a /f "%APPDATA%\Microsoft\Installer"
icacls "%APPDATA%\Microsoft\Installer" /grant:r *BA:(OI)(CI)(F)
*SY:(OI)(CI)(F)
---
[1] A security context (access token) is allowed WRITE_DAC access to an object
(to modify its discretionary ACL and security attributes) if the object's
mandatory label allows write access to the token's integrity level and either
the object's discretionary ACL explicitly grants WRITE_DAC access to the
token's user and enabled groups or implicitly grants this access given the
object's discretionary ACL does not contain an "OWNER RIGHTS" entry and the
object's owner is the token's user or in the token's enabled groups. In
particular for a kernel file object (e.g. opening a filesystem file/directory),
WRITE_DAC access is always allowed if an open uses backup semantics and
SeRestorePrivilege is enabled.
[2] A security context (access token) is allowed WRITE_OWNER access to an
object (to modify its owner, group, and mandatory label) if the token has
SeTakeOwnershipPrivilege enabled or if the object's mandatory label allows
write access to the token's integrity level and the object's discretionary ACL
grants WRITE_OWNER access to the token's user and enabled groups. The object's
owner can be set to any security principal if the token has SeRestorePrivilege
enabled, else it's limited to the access token user and any of the enabled
groups in the access token that is flagged SE_GROUP_OWNER (typically the
Administrators group). In particular for a kernel file object (e.g. opening a
filesystem file/directory), WRITE_OWNER access is always allowed if an open
uses backup semantics and SeRestorePrivilege is enabled.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41961>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
