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

[Eryk Sun]

Eryk Sun  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steve Dower]

Steve Dower  added the comment:

> 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.

Yeah, I'd assumed the most likely cause was the ACLs having been reset on the 
machine in question, though I'd expect that to cause most installs to fail. It 
might be that Python is the first/only MSI that the user has tried though?

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. So I 
wonder if something else is at play?

Also, did your change reproduce the "Error: 0"? Or did you get an actual error 
code?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eryk Sun]

Eryk Sun  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steve Dower]

Steve Dower  added the comment:

Suspicious points:
* error 0 means success, so it shouldn't be popping up an error
* 'Installer\' is a directory, not a file
* %AppData%\Microsoft\Installer is normally readable by Everyone, but only 
writable by Administrators, even in the user's directory

So I assume the error came back from the Windows Installer service which 
couldn't write to the folder for some reason. It may just be system permissions 
or corrupt ACLs (waiting on user logs for more ideas here).

Anyone else know of any possible causes for this? I'm not sure if it's anything 
we could even prevent, but maybe we can make it easier to troubleshoot.

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steve Dower]

New submission from Steve Dower :

Original report: 
https://twitter.com/Steve_Casselman/status/1313564671652159488?s=20

A user received MSI error 1926 in a popup dialog, text reading:

> Could not set file security for file 
> 'C:\Users\sc\AppData\Roaming\Microsoft\Installer\'. Error: 0. Verify that you 
> have sufficient privileges to modify the security permissions for this file.

OS version: 18362.1082 (Windows 10 Home 1903)

--
components: Windows
messages: 378141
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: Windows install failure "could not set file security"
type: behavior
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com