我可以将文件放在哪里,以便非管理员可以编辑它们并可供所有用户访问?

发布于 2024-11-09 17:03:14 字数 257 浏览 0 评论 0原文

我正在开发一个具有静默更新程序的 Windows 应用程序,因此需要能够覆盖可执行文件。

该应用程序还加载一些 .dll

我尝试将可执行文件和 dll 放入应用程序数据文件夹中,但 Visual Studio 向我发出警告,说明所有用户将无法访问这些文件。

我尝试将可执行文件放在应用程序数据文件夹中,将 dll 放在程序文件文件夹中,但应用程序崩溃了,因为无法加载 dll。

我怎样才能 A) 删除警告或 B) 以更好的方式组织一切?

I'm developing a Windows application that has a silent updater, so the executable needs to be able to be overwritten.

The application also loads some .dlls

I tried putting the executable and dlls in the application data folder, but visual studio give me a warning about how the files will not be accessible to all users.

I tried putting the executable in the application data folder and the dlls in the program files folder but the application crashed because the dlls could not be loaded.

How can I either A) remove the warning or B) organize everything in a better way?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

注定孤独终老 2024-11-16 17:03:14

系统上没有这样的文件夹。我的一些想法是:

  • 使用 GAC。据我所知,如果您将二进制文件捆绑为数字签名程序集,GAC 将允许静默安装和“升级”。 (此处,安全性是公钥作为程序集 ID 的一部分所固有的,因此 GAC 中的结果并不重要,只要它经过签名,“恶意软件”程序集就无法冒充已签名的程序集)< /p>

  • < p>使用基于 MSI 的安装程序:同样,在初始管理安装后,MSI 安装程序将允许对现有数字签名内容进行静默安装补丁。这里的安全性是管理员首先授予安装权限所固有的。可以确认签名的补丁 MSI 来自同一发布者,因此 MSI 不需要重新提示许可)。

  • 将主要二进制文件安装到具有 UAC 提升的共享位置。将补丁二进制文件存储在每个用户的文件夹中。这可以防止非管理员用户覆盖彼此的文件。可能存在一些冗余,但那又怎样。

  • 最后(也是最不重要的),创建您自己的文件夹,几乎可以放在您想要的任何位置。从 Windows 安全角度来看,在创建时该软件是新文件夹的所有者,并且作为所有者,您拥有调整新文件夹的 ACL 的隐式权限。因此,您的初始安装过程(以用户或管理员身份运行)可以(在可以成功创建的文件夹上)调整文件夹的 ACL,以授予“用户”组可继承的 R/W 访问权限。任何用户随后在该文件夹中创建的所有文件都可供所有用户读取和写入(来宾除外(并且您确实不想授予来宾用户对任何内容的写访问权限)。

最后一个选项是一个安全问题,因为普通用户不应该能够影响其他用户的执行环境。 R/W 访问”意味着普通用户可以安装木马或以其他方式篡改系统上其他用户的数据,这实质上将所有用户提升为临时管理员。

  • 更安全的角度是,在初始安装期间,将更新代理安装为服务。然后,每个用户帐户上运行的非提升软件将使用某种 IPC 连接到该服务,该服务以 SYSTEM 身份运行,将有权更新用户帐户无权访问的位置中的文件。

这是一个相当复杂的解决方案,本质上是重新发明轮子 - MSI 安装程序使用服务代理组件来执行升级,而无需 UAC 提示。

There is no such folder on the system. Some ideas I have are:

  • Use the GAC. As far as I am aware, if you bundle your binaries as a digitally signed assembly, the GAC will allow both silent installs and "upgrades". (Here the security is inherent in the public key being part of the assembly id, so it doesn't matter what ends up in the GAC, as long as it's signed, a "malware" assembly can't impersonate a signed assembly)

  • Use an MSI based installer: Again, After an initial administrative install the MSI installer will allow the silent install of patches to existing digitally signed content. Here the security is inherent in the administrator first giving permission for the install. The signed patch MSIs can be confirmed to come from the same publisher so MSI doesn't need to re-prompt for permission).

  • Install the primary binaries to a shared location with UAC elevation. Store patch binaries in a per-user folder. This prevents non administrator users overwriting each others files. There is some redundancy potentially, but so what.

  • Lastly (and leastly), create your own folder, pretty much wherever you want. At creation time the software is the owner of the new folder from a windows security point of view, and, as the owner, you have implicit permission to adjust the ACL's of the new folder. So your initial install process, run as a user or administrator, can, (on folders it can successfully create) adjust the ACL of the folder to give the "Users" group inheritable R/W access. All files subsequently created in the folder by any user would then be readable and writeable by all users (except guest (and you really DON'T want to give Guest users write access to anything).

This last option is a security issue as regular users should not be able to effect the execution environment of other users. "Users R/W access" means that regular users could install Trojans or otherwise tamper with other users data on the system, which has, in essence, elevated all users to ad hoc administrators.

  • A more secure angle is, during the initial install, to install an update agent as a service. The non elevated software running on each users account would then use some kind of IPC to connect to the service, which, running as SYSTEM, would have permission to update files in locations the User account's don't have access to.

This is quite a complicated solution and essentially re-invents the wheel - the MSI installer uses a service agent component to perform upgrades with no UAC prompts.

半寸时光 2024-11-16 17:03:14

可执行文件和 Dll 应该始终位于程序文件中。更新程序应通过 UAC 处理权限提升。

Executable and Dlls should always go in Program Files. The updater should handle the priviledge elevation through UAC.

青衫负雪 2024-11-16 17:03:14

Chrome 也有静默更新程序,整个可执行文件保存在“用户”文件夹中。
就我而言,在 Windows 7 上,它保存在:C:\Users\我的帐户名称\AppData\Local\Google

您还应该查看 Environment.SpecialFolder 枚举。

Chrome has silent updater too and whole executable is saved in Users folder.
In my case, on windows 7, it is saved in : C:\Users\my account name\AppData\Local\Google

You should also check out Environment.SpecialFolder enumeration.

開玄 2024-11-16 17:03:14

如果你想像 Chrome 那样将它们放在

Environment.GetFolderPath(Environment.SpecialFolder.System)

If you want to do as Chrome does put them under

Environment.GetFolderPath(Environment.SpecialFolder.System)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文