Re: [WiX-devs] PermissionEx enhancements [ wix-Bugs-2127236 ] [ 2016138 ]

[Rob M. <Rob...@mi...>]

Interesting stuff, I need a little time to digest it all... give me a week after PDC since right now I'm crushed behind that.

From: Cody Cutrer [mailto:Co...@cu...]
Sent: Friday, September 26, 2008 09:09
To: Windows Installer XML toolset developer mailing list
Subject: [WiX-devs] PermissionEx enhancements [ wix-Bugs-2127236 ] [ 2016138 ]

Attached are my (major) improvements to the PermissionEx element.  In summary, they add control to inheritance from parent objects, inheritance to child objects and containers, and supports allow, deny, and audit permissions, and allows the user to be specified as a raw SID in string form.

It does change the default behavior of PermissionEx to more closely match the Permission element (by default, it does not inherit the ACL of the parent object, and it sets the ACL as container inherit and object inherit for folders and registry keys - before it only did for folders).  I'm definitely fine with not changing the default behavior, but the initial reason I did these changes is because I was surprised that PermissionEx behaved so differently from Permission.

It adds some extension points for extension attributes on RegistryKey and CreateFolder elements in wix.xsd to allow defining InheritDacl and InheritSacl in util.xsd as attributes.  This allows you to do something like:

<RegistryKey Root="HKCU" Key="Software\PermissionTest" util:InheritDacl="yes">
    <PermissionEx Type="deny" User="Users" Delete="yes" ApplyToSubkeys="no"/>
</RegistryKey>

That would modify the PermissionTest key by just adding a deny entry for that key only to the existing DACL.

<RegistryKey Root="HKCU" Key="Software\PermissionTest">
    <PermissionEx Type="allow" User="Users" Delete="yes" ApplyToSubkeys="no"/>
</RegistryKey>

This example would create a protected DACL that only allows users to delete that key.  No permissions will be inherited.

The patch also improves rollback behavior... Before it would save a copy of the DACL for every entry that would be applied to it.  Now it only saves one copy per object to be modified.  It also saves the SACL.  This could probably be improved to only save the DACL/SACL if the appropriate pieces need to be modified (this may be required for a user only installation that doesn't have permission to modify the SACL... A previous entry that modifies only the DACL would succeed, then the attempt to set another object's SACL would fail, and the rollback would fail because it would try to replace the SACL on the object that only had the DACL modified.

It also fixes two memleaks in ExecSecureObjects... psd and psid were not getting release before getting re-assigned with each iteration.

Finally, I couldn't figure out how to handle the extension attribute on the parent element with the decompiler.

Feedback is appreciated, especially with regards to attribute names, default values, and MSI schema changes (should I be setting the length of the integer columns differently?  What does the modularize attribute do on key columns?).

Cody