如何使用 wix 安装程序拒绝用户的文件夹权限
How to deny folder permission to Users with wix installer
我的目标是将我的应用程序安装到一个文件夹：
- SYSTEM 可读写
- 管理员可读写
- 没有其他任何人的其他权限。
我尝试了 wix Permission 和 PermissionEx 元素的各种组合和排列。
我最近的尝试是这样的：
<CreateFolder>
<util:PermissionEx User="Users" GenericRead="no" Read="no"/>
<util:PermissionEx User="Everyone" GenericRead="no" Read="no"/>
<util:PermissionEx User="Administrators" GenericAll="yes"/>
</CreateFolder>
在 Component 元素内。
我的结果总是一样的：用户仍然显示 读取、读取和执行[=43] 的权限 =]，并在已安装的文件夹中列出文件夹内容。
我的目标与Restrict access to a folder installed using wix installer
非常相似
我也考虑过WIX: Giving Permissions to a folder and Wix: How to set permissions for folder and all sub folders。
我只是想知道您的总体目标是什么（可能有多个选项）：
- 目标是防止普通用户运行安装应用程序吗？ （if so, you could make elevation required for running - 不太好，但应该可以工作。普通用户在应用程序启动时会被要求输入管理员密码。如果他们没有，他们就不能运行 应用程序 - 据我所知 - 除非他们提升的管理员帐户没有密码！).
- 目标是防止普通用户能够列出有问题的实际文件夹的内容吗？替换 ACL（禁用继承权限）并只为您希望能够访问该文件夹的用户/用户/组添加访问权限应该可以解决问题。不需要普通用户的拒绝权利或特定权利。换句话说，只需替换现有的 ACL 并为管理员添加通用写入和为 SYSTEM 添加完整权限？
我相信您敏锐地意识到，修改 ACL 会产生许多副作用，尤其是拒绝权限（在 self-repair 期间会发生什么？）。我现在没有时间测试特定的 ACL，但如果您仍然需要它，我明天会再次检查。我认为需要管理员权限选项可能适合您？
快Mock-Up
只想添加一个 quick way 来测试我发现的权限。只需在 Windows Explorer 中根据需要修改 ACL 权限即可。然后启动提升的命令提示符并导航到要捕获其 ACL 的文件夹。然后去：
cacls.exe foldername /s
这应该显示 SDDL string that you can dump straight in WiX to use the new, built-in LockPermissionEx table in MSI files (MSI 5 only!):
<Component Feature="ProductFeature">
<File Source="Files\Test.exe" />
<CreateFolder>
<PermissionEx Id="p1" Sddl="D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a8;;;BU)" />
</CreateFolder>
</Component>
上面应该产生一个文件夹，该文件夹对 SYSTEM、管理员和普通用户具有 "special access" 的完全访问权限（遍历文件夹/运行 文件、读取属性、读取扩展属性、读取访问权限）。如下所述，这并不能很好地工作，因为管理员通常 运行 non-elevated 然后冒充普通用户（不能 100% 确定这是如何工作的）。
如您所知，有 many, different WiX elements that relate to permissioning（中页），您还可以使用自定义操作来进行许可（不推荐）。明天再测试一下。 也许提升的 EXE 与受保护的数据文件夹的组合可以工作？或者也许是一种在系统尝试启动它指向的文件而不提升之前使触发快捷方式调用提升的方法。
正在尝试列出一些选项
更新：今天没有做太多测试，但我开始考虑可能的选项列表。其中一些选项只是草草记下，并不真正可行。他们正在排除一些东西，看看他们是否能激发出新的更好的想法。也许可以使用 8、1、2、3 & 6？也许结合？
Combo?：Super-hidden 安装文件夹也是 ACL-locked 并由始终提升的 EXE 访问运行 来自映射驱动器？ （访问 access-based 枚举服务器共享？）：
- 锁定/隐藏和提升：使用 ACL 隐藏子文件夹，然后通过修改应用程序清单在应用程序启动时要求 UAC 提升？单个启动器应用程序 EXE 是否可见？ （可以是 super-hidden？请参阅下一个要点）。
- 不太好security-wise（一旦提升，访问无处不在），但我认为它会起作用，并且没有普通用户能够访问 ACL-protected 数据 sub-folder（虽然他们会看到它 - 但检查下一个选项 super-hidden 文件夹状态 - 可以组合吗？）。
- 我只想提一下，普通用户在尝试调用需要 运行 管理员权限的可执行文件时会被要求输入密码。据我所知，如果没有管理员密码，他们根本无法 运行 该应用程序。可能会在一时兴起时被遗忘，经理可能会错过 运行 应用程序突然需要管理员权限的情况。我已经看到它发生了。
- 虽然公司网络的 组策略 可以阻止，但如果有 password-less、本地管理员帐户（可能在小型企业中很常见），然后 任何标准用户都可以通过无密码 admin-account 提升到管理员权限 - 随意 - 一旦提示输入管理员密码 。
- 容易忘记.
- 巨大的安全漏洞.
- 有一个我从未尝试过的highest available elevation option（仅对管理员帐户提升为管理员权限，否则运行权限有限）。
- 不确定 UAC 被禁用后会发生什么。整个方法可能会失败？或者它可能只是 运行s 不经询问就升高了？ 我不知道.
- 还有进一步的安全问题最好不要按照同样的思路提及，因为任何提升的进程都是有问题的：访问是普遍的而不是特定的（all-access 后台通行证”——除非你limit privileges 好好为账号。
- 不要搞错：提升 EXE 文件最好只用于系统维护和配置由知道自己在做什么的系统管理员。 Elevation 在用于常规公司应用程序的优秀软件工程中没有立足之地。 理论上理论和实践应该没有区别，但实际上有 :-).
- 您可能需要保持主应用程序二进制文件可见，以便任何用户都可以启动它。否则 MSI self-repair 由于指向的文件不可访问而启动。也许 自定义快捷方式标志 可用于立即强制提升？要去看看
创建文件夹Super-Hidden：这可能是一个愚蠢的选择。这取决于您的用例以及这些文件必须如何受到保护？他们只是希望在视线之外，还是必须 "locked" 并且无法访问？ You can set a super-hidden flag for your folder with a simple attrib command:
attrib +s +h "C:\Folder\"
该文件夹现在 super-hidden 就像一些核心 OS 文件夹一样。这样的文件夹不会出现在 Windows 资源管理器或命令行中，除非您采取特殊步骤使其出现（显示隐藏的 OS 文件 - 见上文 link）。但是如果用户知道该文件夹在那里，则该文件夹不会被锁定以供访问。也许您可以将 super-hidden 标志与另一种方法结合使用？ （隐藏文件夹并锁定它？）
Access-Based Enumeration Server Share：这个新的服务器特性似乎是你真正需要的.它隐藏了相关用户没有访问权限的文件夹，但我认为该功能不能在普通 PC（非服务器）上使用。也许可以？稍后要检查的东西。我不知道是否可以选择将文件存储在服务器共享上？
- 数据库连接：这肯定是不可能的 - 出于某种原因 - 但房间里的大象就是为什么这个数据访问（如果它与 data-access 相关）不是通过数据库和经过身份验证的连接完成的？
- Web-Application：与 4 一样，显然有充分的理由阻止您将其设为 web-application？或者我猜它可能是我们所知道的 web-application。想到什么就记下来，多多包涵。
- 通过登录脚本/组策略映射驱动器：我想你可以通过登录脚本使用映射驱动器（或者更好， using group policy) 哪个只映射给应该有权访问该应用程序的用户？我认为简单的应用程序可以 运行 直接关闭这样的映射驱动器。也无需安装。或者您将二进制文件保存在映射驱动器中，并将其余文件保存在本地？
- NTFS symbolic link：试着记下我所说的所有想到的东西。我从未使用过此功能，但我知道 NTFS symbolic link 可以指向服务器共享。如果该服务器支持基于访问的枚举怎么办？这会隐藏某些用户的文件和文件夹吗？列出你没有尝试过的选项是不明智的，但也许其他人阅读它会有更好的主意？
- 自定义 NT 访问组：我想知道最简单的 "fix" 是否是创建一个本地或您需要成为其成员才能完全访问您的文件夹的 AD 访问组。因此，您删除所有 built-in 组，添加 SYSTEM 和具有完全访问权限的自定义组以及技术上需要的任何其他组（创建者？）。 我还没有测试过这个（也许这是你尝试的第一件事？）。将这样的本地组与 super-hidden 文件夹结合起来听起来像是一种选择。普通用户不会轻易看到该文件夹，即使他们看到了也无法访问它？还有启动快捷方式可见性的问题？ （如果用户无法启动应用程序，为什么要看到它）。
如果你能找到（或创建）一个你需要权限的文件夹，我会先用CACLS.exe来显示SDDL格式的权限。完成后，您可以在 MSI 中使用 MsiLockPermissionsEx table。
WiX 似乎不直接支持 MsiLockPermissionsEx table，因为似乎没有办法只粘贴 SDDL 字符串以应用于某些内容，除非我已经错过了某个地方。
我的目标是将我的应用程序安装到一个文件夹：
- SYSTEM 可读写
- 管理员可读写
- 没有其他任何人的其他权限。
我尝试了 wix Permission 和 PermissionEx 元素的各种组合和排列。
我最近的尝试是这样的：
<CreateFolder>
<util:PermissionEx User="Users" GenericRead="no" Read="no"/>
<util:PermissionEx User="Everyone" GenericRead="no" Read="no"/>
<util:PermissionEx User="Administrators" GenericAll="yes"/>
</CreateFolder>
在 Component 元素内。
我的结果总是一样的：用户仍然显示 读取、读取和执行[=43] 的权限 =]，并在已安装的文件夹中列出文件夹内容。
我的目标与Restrict access to a folder installed using wix installer
非常相似我也考虑过WIX: Giving Permissions to a folder and Wix: How to set permissions for folder and all sub folders。
我只是想知道您的总体目标是什么（可能有多个选项）：
- 目标是防止普通用户运行安装应用程序吗？ （if so, you could make elevation required for running - 不太好，但应该可以工作。普通用户在应用程序启动时会被要求输入管理员密码。如果他们没有，他们就不能运行 应用程序 - 据我所知 - 除非他们提升的管理员帐户没有密码！).
- 目标是防止普通用户能够列出有问题的实际文件夹的内容吗？替换 ACL（禁用继承权限）并只为您希望能够访问该文件夹的用户/用户/组添加访问权限应该可以解决问题。不需要普通用户的拒绝权利或特定权利。换句话说，只需替换现有的 ACL 并为管理员添加通用写入和为 SYSTEM 添加完整权限？
我相信您敏锐地意识到，修改 ACL 会产生许多副作用，尤其是拒绝权限（在 self-repair 期间会发生什么？）。我现在没有时间测试特定的 ACL，但如果您仍然需要它，我明天会再次检查。我认为需要管理员权限选项可能适合您？
快Mock-Up
只想添加一个 quick way 来测试我发现的权限。只需在 Windows Explorer 中根据需要修改 ACL 权限即可。然后启动提升的命令提示符并导航到要捕获其 ACL 的文件夹。然后去：
cacls.exe foldername /s
这应该显示 SDDL string that you can dump straight in WiX to use the new, built-in LockPermissionEx table in MSI files (MSI 5 only!):
<Component Feature="ProductFeature">
<File Source="Files\Test.exe" />
<CreateFolder>
<PermissionEx Id="p1" Sddl="D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a8;;;BU)" />
</CreateFolder>
</Component>
上面应该产生一个文件夹，该文件夹对 SYSTEM、管理员和普通用户具有 "special access" 的完全访问权限（遍历文件夹/运行 文件、读取属性、读取扩展属性、读取访问权限）。如下所述，这并不能很好地工作，因为管理员通常 运行 non-elevated 然后冒充普通用户（不能 100% 确定这是如何工作的）。
如您所知，有 many, different WiX elements that relate to permissioning（中页），您还可以使用自定义操作来进行许可（不推荐）。明天再测试一下。 也许提升的 EXE 与受保护的数据文件夹的组合可以工作？或者也许是一种在系统尝试启动它指向的文件而不提升之前使触发快捷方式调用提升的方法。
正在尝试列出一些选项
更新：今天没有做太多测试，但我开始考虑可能的选项列表。其中一些选项只是草草记下，并不真正可行。他们正在排除一些东西，看看他们是否能激发出新的更好的想法。也许可以使用 8、1、2、3 & 6？也许结合？
Combo?：Super-hidden 安装文件夹也是 ACL-locked 并由始终提升的 EXE 访问运行 来自映射驱动器？ （访问 access-based 枚举服务器共享？）：
- 锁定/隐藏和提升：使用 ACL 隐藏子文件夹，然后通过修改应用程序清单在应用程序启动时要求 UAC 提升？单个启动器应用程序 EXE 是否可见？ （可以是 super-hidden？请参阅下一个要点）。
- 不太好security-wise（一旦提升，访问无处不在），但我认为它会起作用，并且没有普通用户能够访问 ACL-protected 数据 sub-folder（虽然他们会看到它 - 但检查下一个选项 super-hidden 文件夹状态 - 可以组合吗？）。
- 我只想提一下，普通用户在尝试调用需要 运行 管理员权限的可执行文件时会被要求输入密码。据我所知，如果没有管理员密码，他们根本无法 运行 该应用程序。可能会在一时兴起时被遗忘，经理可能会错过 运行 应用程序突然需要管理员权限的情况。我已经看到它发生了。
- 虽然公司网络的 组策略 可以阻止，但如果有 password-less、本地管理员帐户（可能在小型企业中很常见），然后 任何标准用户都可以通过无密码 admin-account 提升到管理员权限 - 随意 - 一旦提示输入管理员密码 。
- 容易忘记.
- 巨大的安全漏洞.
- 有一个我从未尝试过的highest available elevation option（仅对管理员帐户提升为管理员权限，否则运行权限有限）。
- 不确定 UAC 被禁用后会发生什么。整个方法可能会失败？或者它可能只是 运行s 不经询问就升高了？ 我不知道.
- 还有进一步的安全问题最好不要按照同样的思路提及，因为任何提升的进程都是有问题的：访问是普遍的而不是特定的（all-access 后台通行证”——除非你limit privileges 好好为账号。
- 不要搞错：提升 EXE 文件最好只用于系统维护和配置由知道自己在做什么的系统管理员。 Elevation 在用于常规公司应用程序的优秀软件工程中没有立足之地。 理论上理论和实践应该没有区别，但实际上有 :-).
- 您可能需要保持主应用程序二进制文件可见，以便任何用户都可以启动它。否则 MSI self-repair 由于指向的文件不可访问而启动。也许 自定义快捷方式标志 可用于立即强制提升？要去看看
- 不太好security-wise（一旦提升，访问无处不在），但我认为它会起作用，并且没有普通用户能够访问 ACL-protected 数据 sub-folder（虽然他们会看到它 - 但检查下一个选项 super-hidden 文件夹状态 - 可以组合吗？）。
创建文件夹Super-Hidden：这可能是一个愚蠢的选择。这取决于您的用例以及这些文件必须如何受到保护？他们只是希望在视线之外，还是必须 "locked" 并且无法访问？ You can set a super-hidden flag for your folder with a simple attrib command:
attrib +s +h "C:\Folder\"该文件夹现在 super-hidden 就像一些核心 OS 文件夹一样。这样的文件夹不会出现在 Windows 资源管理器或命令行中，除非您采取特殊步骤使其出现（显示隐藏的 OS 文件 - 见上文 link）。但是如果用户知道该文件夹在那里，则该文件夹不会被锁定以供访问。也许您可以将 super-hidden 标志与另一种方法结合使用？ （隐藏文件夹并锁定它？）
Access-Based Enumeration Server Share：这个新的服务器特性似乎是你真正需要的.它隐藏了相关用户没有访问权限的文件夹，但我认为该功能不能在普通 PC（非服务器）上使用。也许可以？稍后要检查的东西。我不知道是否可以选择将文件存储在服务器共享上？
- 数据库连接：这肯定是不可能的 - 出于某种原因 - 但房间里的大象就是为什么这个数据访问（如果它与 data-access 相关）不是通过数据库和经过身份验证的连接完成的？
- Web-Application：与 4 一样，显然有充分的理由阻止您将其设为 web-application？或者我猜它可能是我们所知道的 web-application。想到什么就记下来，多多包涵。
- 通过登录脚本/组策略映射驱动器：我想你可以通过登录脚本使用映射驱动器（或者更好， using group policy) 哪个只映射给应该有权访问该应用程序的用户？我认为简单的应用程序可以 运行 直接关闭这样的映射驱动器。也无需安装。或者您将二进制文件保存在映射驱动器中，并将其余文件保存在本地？
- NTFS symbolic link：试着记下我所说的所有想到的东西。我从未使用过此功能，但我知道 NTFS symbolic link 可以指向服务器共享。如果该服务器支持基于访问的枚举怎么办？这会隐藏某些用户的文件和文件夹吗？列出你没有尝试过的选项是不明智的，但也许其他人阅读它会有更好的主意？
- 自定义 NT 访问组：我想知道最简单的 "fix" 是否是创建一个本地或您需要成为其成员才能完全访问您的文件夹的 AD 访问组。因此，您删除所有 built-in 组，添加 SYSTEM 和具有完全访问权限的自定义组以及技术上需要的任何其他组（创建者？）。 我还没有测试过这个（也许这是你尝试的第一件事？）。将这样的本地组与 super-hidden 文件夹结合起来听起来像是一种选择。普通用户不会轻易看到该文件夹，即使他们看到了也无法访问它？还有启动快捷方式可见性的问题？ （如果用户无法启动应用程序，为什么要看到它）。
如果你能找到（或创建）一个你需要权限的文件夹，我会先用CACLS.exe来显示SDDL格式的权限。完成后，您可以在 MSI 中使用 MsiLockPermissionsEx table。
WiX 似乎不直接支持 MsiLockPermissionsEx table，因为似乎没有办法只粘贴 SDDL 字符串以应用于某些内容，除非我已经错过了某个地方。