我想知道你的总体目标是什么（可能有几个选项适用）：
- 目标是防止普通用户运行应用程序吗？（如果是的话，您可以要求提高权限以运行 - 不太好，但应该有效。普通用户在启动应用程序时会被要求输入管理员密码。如果他们没有密码，他们就无法运行应用程序 - 据我所知 - 除非他们提升权限的管理员帐户没有密码！）。
- 目标是防止普通用户能够列出相关文件夹的内容吗？替换ACL（禁用继承权限），并仅为您想要访问文件夹的用户/用户组添加访问权限即可。不需要拒绝权限或特定权限的普通用户。换句话说，只需替换现有的ACL，并为管理员添加通用写入权限和SYSTEM的完全权限即可？
我相信你已经非常清楚，修改访问控制列表可能会产生许多副作用，特别是拒绝权限（自我修复期间会发生什么？）。我现在没有时间测试特定的ACL，但如果你还需要，我明天会再次检查。我认为“需要管理员权限”选项可能适合你？
快速模拟
我只想添加一个 快速测试权限的方法，以便测试。只需在Windows资源管理器中按需要修改ACL权限。然后启动提升的命令提示符并导航到要捕获ACL的文件夹。然后执行以下操作：
cacls.exe foldername /s
这应该显示一个
SDDL字符串，你可以直接在WiX中倾倒它以使用MSI文件中的新内置
LockPermissionEx表（
仅适用于MSI 5！）：
<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、管理员有完全访问权限，并且对于普通用户具有“遍历文件夹/运行文件、读取属性、读取扩展属性和读取访问权限”的特殊访问权限。正如下面所述，这并不是很好的解决方案，因为管理员通常以非提升方式运行，然后模拟普通用户（不确定这究竟是如何工作的）。
如你所知，有
许多与权限相关的不同WiX元素（页面中部），你也可以使用自定义操作进行权限设置（不建议这样做）。明天将进一步测试。或许可以通过提升EXE和保护数据文件夹的组合来解决问题？或者在系统尝试启动指向未提升文件的快捷方式之前，让触发快捷方式调用提升？
尝试列出一些选项
更新: 今天没有进行太多测试，但我开始思考可能的选项列表。其中一些选项只是随意记下来的，并不真正可行。它们用于排除一些方案并查看是否能激发新的更好的想法。也许可以使用 8, 1, 2, 3 和 6？也许可以组合使用？
组合？: 超级隐藏的安装文件夹，也是 ACL 锁定的，并通过映射驱动器上运行的始终升级的 EXE 访问（访问基于访问控制的枚举服务器共享）？
- Lock / Hide & Elevate: hide sub folder with ACLs, then require UAC elevation on application launch by modifying the application manifest? A single launcher application EXE would be visible? (Can be super-hidden? See next bullet point).
- Not great security-wise (once you elevate, access is pervasive), but I think it will work, and no regular user would be able to access the ACL-protected data sub-folder (they will see it though - but check out the next option with super-hidden folder status - combination possible?).
- I will just mention that regular users will be asked for a password when trying to invoke executables that require admin rights to run. Without an admin password they can't run the application at all as far as I know. Can be forgotten in the heat of the moment, and a manager could miss that suddenly admin rights are required to run the application at all. I have seen it happen.
- Though preventable by group policy for corporate networks, if there is a password-less, local administrator account (which could be common in small businesses), then any standard user can elevate to admin rights via that passwordless admin-account - at will - once prompted for an admin password.
- Easy to forget.
- Huge security hole.
- There is the highest available elevation option that I have never tried (elevate to admin rights only for admin accounts, otherwise run with limited rights).
- Not sure what happens if UAC is disabled. The whole approach probably fails? Or maybe it just runs elevated without asking? I don't know.
- There are further security problems that are best not to mention along the same lines as any elevated process is problematic: access is pervasive and not specific ("all-access backstage pass" - unless you limit privileges well for the account).
- Make no mistake about it: elevating EXE files should ideally only be used to allow system maintenance and configuration by system administrators who know what they are doing. Elevation has no place in good software engineering for regular corporate applications. In theory there should be no difference between theory and practice, but in practice there is :-).
- You would likely need to keep the main application binary visible for it to be launchable by any users though. Otherwise MSI self-repair kicks in as the file pointed to is inaccessible. Maybe a custom shortcut flag is available to force elevation immediately? Going to have a look.
Make Folder Super-Hidden: this is probably a silly option. It depends on your use case and how protected these files must be? Are they just desired out of view, or do they have to be "locked" and inaccessible? You can set a super-hidden flag for your folder with a simple attrib command:
attrib +s +h "C:\Folder\"
The folder is now super-hidden like some core OS folders. Such a folder doesn't show up in Windows Explorer or in command line unless you take special steps to make it appear (show hidden OS files - see above link). But the folder is not locked for access if the users know the folder is there. Maybe you can combine the super-hidden flag with another approach? (hide the folder and lock it too?)
Access-Based Enumeration Server Share: this new server feature seems to be what you need actually. It hides folders that the user in question does not have access rights to, but I don't think the feature can be used on regular PCs (non servers). Perhaps it can? Something to check later. I don't know if storing files on a server share is an option or not?
- Database Connection: this is surely out of the question - for some reason - but the elephant in the room is why this data access (if it relates to data-access) isn't done via a database and an authenticated connection?
- Web-Application: as with 4, a good reason obviously exists preventing you from making this a web-application? Or I guess it could be a web-application for all we know. Jotting down whatever comes to mind, bear with me.
- Mapped Drive via Logon Script / Group Policy: I suppose you could use a mapped drive via a logon script (or better, using group policy) which is mapped only for the users who should have access to the application? Simple applications could run straight off such a mapped drive I think. No installation to do either. Or you keep a binary in the mapped drive, and the rest of the files locally?
- NTFS symbolic link: trying to jot down everything that comes to mind as I said. I have never used this feature, but I know a NTFS symbolic link could point to a server share. What if that server supports access based enumeration? Would this hide the files and folders for some users? Unwise to list options you haven't tried, but maybe someone else gets a better idea reading it?
- Custom NT Access Group: I am wondering if the simplest "fix" of all would be to create a local or AD access group which you need to be a member of to be able to access your folder at all. So you remove all built-in groups, add SYSTEM and your custom group with full access and any other groups that are technically needed (creator?). I haven't tested this (maybe it was the first thing you tried?). Combining such a local group with a super-hidden folder sounds like an option. No regular users will easily see the folder, and if they do they can't access it? There is still the issue of the launching shortcut visibility? (why should users see it, if they can't launch the application).
