[issue41961] Windows install failure "could not set file security"

[Eryk Sun]

Eryk Sun <eryksun at 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 <report at bugs.python.org>
<https://bugs.python.org/issue41961>
_______________________________________