CoCreateInstance 上的 E_ACCESSDENIED，它曾经在其中工作
我有一些代码曾经可以工作，但最近停止了。它位于 Adobe Reader 插件中，最新的 Reader 版本具有“保护模式”，这导致了我的问题。
我的插件可以加载一些正常的 dll，这些 dll 是在进程中加载的：
MyNormalLib::IMyClassPtr foo;
HRESULT hr = foo.CreateInstance(__uuidof(MyNormalLib::MyClass));
但是当我尝试获取指向我的服务的 com 指针（在同一台计算机上运行）时：
MyOtherLib::IMyServicePtr bar;
HRESULT hr = bar.CreateInstance(__uuidof(MyOtherLib::MyService));
我的 HRESULT 得到 E_ACCESSDENIED 。
这曾经工作得很好，直到 Adobe Reader X 出现。如果没有保护模式，Adobe 会正常运行并且一切正常。在保护模式下，Adobe 会生成另一个 Reader 进程，但对其有一些限制。使用 Process Explorer 查看此内容，我可以看到父 Reader 进程的“安全性”选项卡几乎将所有内容设置为“强制”；但是子Reader进程将大多数组设置为“拒绝，强制”，一些“强制，限制”，一些只是强制。如果这很重要，我可以提供更多详细信息。
所有进程（我的服务和两个 Reader）都以同一用户（我）运行。我有管理员权限，如果这很重要的话。
尝试访问我自己的服务时，什么会导致 AccessDenied 错误？我必须跨越哪些安全障碍才能使其发挥作用？
I have some code that used to work, but recently stopped. It's in an Adobe Reader Plugin, and the latest Reader version has a "Protected Mode" which causes my problem.
My plugin can load some of my normal dlls, which load in-process:
MyNormalLib::IMyClassPtr foo;
HRESULT hr = foo.CreateInstance(__uuidof(MyNormalLib::MyClass));
But when I try to get a com pointer to my service (running on the same machine):
MyOtherLib::IMyServicePtr bar;
HRESULT hr = bar.CreateInstance(__uuidof(MyOtherLib::MyService));
I get E_ACCESSDENIED for my HRESULT.
This used to work fine, until Adobe Reader X came along. Without Protected Mode, Adobe runs normally and everything works. With Protected Mode, Adobe spawns another Reader process, with some restrictions on it. Looking at this with Process Explorer, I can see that the Security Tab for the parent Reader process has pretty much everything set to Mandatory; but the child Reader process has most groups set to "Deny, Mandatory", some "Mandatory, Restricted", some are just Mandatory. If this matters, I can provide more details.
All processes (my service and both Reader) are run as the same user -- me. I have admin rights, if that matters.
What can cause an AccessDenied error when trying to reach my own service? What security hoops do I have to jump through to get this to work?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
受限进程没有管理员权限。这几乎就是本次练习的重点 - Reader X 会从其令牌中删除尽可能多的权利，这样即使它被盗，您的计算机也不会被盗。
（这基本上也是 UAC 的工作原理，一旦禁用管理员组，您必须进入内核以获得重新启用管理员组的权限）。
基本上，您需要查看 Reader X 拥有的权限，并确保您的组件可以与这些权限一起使用。进程监视器是您的朋友 - 只需过滤 DENIED，问题就会立即出现在您面前！
The restricted process does not have admin rights. That's pretty much the point of the exercise - Reader X drops as many rights as it can from its token so that if it is pwned your computer is not.
(That's basically how UAC works too, you have to go to the Kernel to get permission to re-enable your Administrator group once you have disabled it).
Basically you need to look at the privs that Reader X has, and make sure your component can be used with those permissions. Process Monitor is your friend - just filter for DENIED and the problems will pop right out at you!