如何使用 wix 安装程序拒绝用户的文件夹权限 [英] How to deny folder permission to Users with wix installer

问题描述

我的目标是将我的应用程序安装到一个文件夹中:

My goal is to install my application to a folder:

• 系统可读可写
• 管理员可读可写
• 没有其他任何人的其他权限.

我尝试了 wix Permission 和 PermissionEx 元素的各种组合和排列.

I've tried various combinations and arrangements of the wix Permission and PermissionEx elements.

我最近的尝试是这样的:

My latest attempt is this:

<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 元素内.

我的结果始终相同:用户仍​​然显示对读取、读取和执行以及列表文件夹内容的权限em> 在已安装的文件夹中.

My results are always the same: Users still show permission for Read, Read and Execute, and Listfolder contents on the installed folder.

我的目标与限制对文件夹的访问非常相似使用 wix 安装程序安装

我还考虑过WIX:授予文件夹权限和Wix:如何为文件夹和所有设置权限子文件夹.

推荐答案

我只是想知道你的总体目标是什么(可以有几个选项):

• 目标是阻止普通用户运行应用程序吗?(如果是这样，你可以使运行需要提升 - 不是很好，但应该可以.普通用户会在应用程序启动时被要求输入管理员密码.如果他们没有，他们将无法运行应用程序 - 据我所知 - 除非他们提升的管理员帐户没有密码！).
• 目标是防止普通用户列出相关文件夹的内容吗?替换 ACL(禁用继承的权限)并只为您希望能够访问该文件夹的用户/用户/组添加访问权限应该可以解决问题.不需要普通用户的拒绝权限或特定权限.换句话说，只是替换现有的 ACL 并为管理员添加通用写入和为系统添加完全权限?

• Is the goal to prevent regular users from running the application? (if so, you could make elevation required for running - not great, but should work. Regular users would be asked for admin password on application launch. If they don't have it, they can't run the application - as far as I know - unless the admin account they elevate with has no password!).
• Is the goal to prevent regular users from being able to list the content of the actual folder in question? Replacing the ACL (disable inherited rights) and only adding access for the user / users / groups you want to be able to access the folder should do the trick. No deny rights or specific rights for regular users needed. In other words just replace the existing ACL and add generic write for Administrators and full rights for SYSTEM?

我相信您很清楚，修改 ACL 会产生许多副作用，尤其是拒绝权限(在自我修复期间会发生什么?).我现在没有时间测试特定的 ACL，但是如果您仍然需要它，我明天会再次检查.我认为需要管理员权限选项可能适合您?

As I am sure you are acutely aware of, modifying ACLs can have many side effects, especially deny rights (what happens during self-repair?). I don't have time to test specific ACLs right now, but I will check again tomorrow if you still need it. I think the require admin rights option might work for you?

只想添加一个快速方法来测试我发现的权限.只需在 Windows 资源管理器中根据需要修改 ACL 权限.然后启动提升的命令提示符并导航到要捕获其 ACL 的文件夹.然后去:

Just want to add a quick way to test permissions that I discovered. Just modify the ACL permissions as desired in Windows Explorer. Then launch an elevated command prompt and navigate to the folder whose ACL you want to capture. Then go:

cacls.exe foldername /s

这应该显示 SDDL 字符串，您可以直接在 WiX 中转储以在 MSI 文件中使用新的内置 LockPermissionEx 表 (仅限 MSI 5！):

This should show a 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="FilesTest.exe" />
   <CreateFolder>
     <PermissionEx Id="p1" Sddl="D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a8;;;BU)" />
   </CreateFolder>
</Component>

以上应该产生一个文件夹，该文件夹对系统、管理员和特殊访问"具有完全访问权限，对普通用户(遍历文件夹/运行文件、读取属性、读取扩展属性、读取访问权限).如下所述，这不太好用，因为管理员通常以非提升的方式运行，然后冒充普通用户(不能 100% 确定这实际上是如何工作的).

The above should yield a folder that has full access for SYSTEM, Administrators and "special access" for regular users (traverse folder / run file, read attributes, read extended attributes, read access). As stated below this does not work too well since administrators generally run non-elevated and then impersonate regular users (not 100% sure how this really works).

如您所知，有许多与许可相关的不同 WiX 元素(中页)，您还可以使用自定义操作进行许可(不推荐).明天再测试一点.也许将提升的 EXE 与受保护的数据文件夹结合起来可以工作?或者也许是一种在系统尝试启动它指向的文件之前调用提升的方法.

As you know there are many, different WiX elements that relate to permissioning (mid page), and you can also use custom actions to do permissioning (not recommended). Going to test a little bit more tomorrow. Maybe a combination of an elevated EXE with a protected data folder could work? Or maybe a way to make the triggering shortcut invoke elevation before the system tries to launch the file it points to without elevation.

更新:今天没有进行太多测试，但我开始考虑可能的选项列表.其中一些选项只是草草记下，并不真正可行.他们要排除一些东西，看看他们是否能激发出新的更好的想法.也许 8, 1, 2, 3 &6 可以用吗?也许组合?

UPDATE: Not much testing done today, but I got thinking about the list of possible options. Some of these options are just jotted down and not really viable. They are in to rule stuff out and to see if they could spark new and better ideas. Maybe 8, 1, 2, 3 & 6 could be used? Maybe in combination?

Combo?:超级隐藏的安装文件夹，它也被 ACL 锁定并由从映射驱动器运行的始终提升的 EXE 访问?(访问基于访问的枚举服务器共享?):

Combo?: Super-hidden installation folder that is also ACL-locked and accessed by an always elevated EXE run from a mapped drive? (accessing an access-based enumeration server share?):

1. 锁定/隐藏和隐藏提升:隐藏带有 ACL 的子文件夹，然后通过修改应用程序清单在应用程序启动时要求 UAC 提升?单个启动器应用程序 EXE 是否可见?(可以超级隐藏吗?见下一个要点).
   • 在安全方面不是很好(一旦你提升，访问无处不在)，但我认为它会起作用，并且没有普通用户能够访问 ACL- 受保护的数据子文件夹(尽管他们会看到它 - 但请查看下一个具有超级隐藏文件夹状态的选项 - 可以组合吗?).
     • 我只想提到普通用户在尝试调用需要管理员权限才能运行的可执行文件时会被要求输入密码.据我所知，如果没有管理员密码，他们根本无法运行该应用程序.一时之间可能会被遗忘，并且经理可能会错过突然需要管理员权限才能运行应用程序的情况.我亲眼所见.
     • 虽然企业网络的组策略可以防止，但如果有一个无密码的本地管理员帐户(这在小型企业中很常见)，那么任何标准用户都可以通过该无密码管理员帐户提升到管理员权限 - 随意 - 一旦提示输入管理员密码.
       • 容易忘记.
       • 巨大的安全漏洞.
       • 有我从未尝试过的最高可用提升选项(仅针对管理员帐户提升到管理员权限，否则以有限的权限运行).

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

将文件夹设为超级隐藏:这可能是一个愚蠢的选择.这取决于您的用例以及这些文件的保护程度?他们只是在视线之外，还是必须被锁定"并且无法访问?您可以设置使用简单的 attrib 命令为您的文件夹设置一个超级隐藏标志:

attrib +s +h "C:Folder"

该文件夹现在像一些核心操作系统文件夹一样被超级隐藏.这样的文件夹不会显示在 Windows 资源管理器或命令行中，除非您采取特殊步骤使其出现(显示隐藏的操作系统文件 - 请参阅上面的链接).但是，如果用户知道文件夹在那里，则该文件夹不会被锁定以供访问.也许您可以将超级隐藏标志与另一种方法结合起来?(隐藏文件夹并锁定它?)

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?)

基于访问的枚举服务器共享:这个新的服务器功能似乎正是您真正需要的.它隐藏了相关用户无权访问的文件夹，但我认为该功能不能在普通 PC(非服务器)上使用.也许可以?有事以后再查.我不知道是否可以将文件存储在服务器共享上?

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?

• 您无法配置 NTFS 权限以对未经授权的用户隐藏文件或文件夹.
• Windows Server 2016 中基于访问的枚举.
• 奇怪的黑客":基于访问的枚举在 Windows 7 上.

这篇关于如何使用 wix 安装程序拒绝用户的文件夹权限的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！