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

[Eryk Sun]

Eryk Sun <eryksun at gmail.com> added the comment:

> It might be that Python is the first/only MSI that the user 
> has tried though?

It's likely the first per-user MSI install attempted since the security of the "Installer" directory was modified. There's no problem with a per-machine install.

> did your change reproduce the "Error: 0"? 

It's the same "Could not set file security for file... Error: 0" dialog, which is created by the python-3.9.0.exe child process that executes from a copy in %TEMP%. 

In Process Monitor, I see the actual access-denied error due to the installer service trying to open the directory with WRITE_DAC and WRITE_OWNER access.

If I also remove the Everyone group that grants read and execute access, the installer service fails at an earlier step, which results in an 0x80070643 fatal installation error.

> It sounds like just resetting the owner isn't enough on its own, 
> but the inherited ACLs should include SYSTEM and not prevent it 
> from working. 

The security descriptor that the installer service sets prevents inheritance of discretionary access control entries (i.e. the DACL is protected):

    >>> sd = GetFileSecurity('Installer', DACL_SECURITY_INFORMATION)
    >>> sd.GetSecurityDescriptorControl()[0] & SE_DACL_PROTECTED
    4096

Thus the entries in the ACL for SYSTEM and Administrators groups are set explicitly instead of inherited from the parent directory. If something else rewrites the security on the directory, it can just as easily protect the DACL from inheritance.

In my first experiment, I had left the entry for Everyone (WD) in the DACL, but, as mentioned above, it turns out that it's required at an earlier step. So a fix has to also add it back:

    >icacls "%APPDATA%\Microsoft\Installer" /grant:r *WD:(OI)(CI)(RX)

Also, in my first message, I manually re-added the SYSTEM and Administrators entries unnecessarily -- though it doesn't hurt to do so. It turns out that all the service needs is for the directory's owner to be set back to the Administrators group. Then it implicitly has WRITE_DAC access. It gets WRITE_OWNER access as well, even though the file security at the time doesn't grant it (the owner of an object does not implicitly have WRITE_OWNER access to it), so presumably the service is temporarily enabling SeTakeOwnershipPrivilege for the process or thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41961>
_______________________________________