1

似乎特权提升是大多数开发人员与之抗争的常见事情，因为大多数时候他们根本没有。我是这样做的，但我正在与一个庞大的后台工作程序作斗争，我试图将我的代码保持在将要使用它的类的本地。鉴于我的后台工作人员在“RunWorkerCompleted”处理程序方法内完成后所做的代码和引用的数量，证明很难接受这是一个可行的替代方案：

作业1：

作业2：

作业3：

我的后台工作人员对我的 MainForm 类的依赖太多了，以至于我无法考虑将整个解决方案发送到具有“管理员”权限的单独进程中。这涉及太多的砍伐和改变。

欧米茄编码器：

在阅读了 70-536 考试的 CAS 后，我知道上述示例中的大部分术语，但我没有看到它是如何以及为什么起作用的？有人可以解释为什么将权限授予“ManagersOnly”方法吗？一旦 PrincipalPolicy 更改为 WindowsPrincipal，接下来的两个步骤看起来就像普通的对象实例化语句，如下所示：

System.AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal, IPrincipal, IIdentity);

显然，不存在这样的重载，但它非常清楚该重载的作用。

问题一： OmegaCoders的例子是如何实现这个效果的？因为它肯定可以工作，因为我的用户是“BUILTIN\Administrators”组的一部分。我正在寻找基于文献的答案，因此请尽可能详细地了解您的感受。

更新 1：

问题 2：我如何将 PrincipalPolicy 恢复到以前的状态......一旦方法返回，我不需要 PrincipalPolicy 仍然设置为“WindowsPrincipal”？？？这样该应用程序就可以按照我的意图以较低特权用户的身份继续运行。

问题3：一旦'ManagersOnly'方法返回，权限是否被丢弃？它是否适用于方法的生命周期？

System.AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.NoPrincipal);

*更新2：*

事实证明这很困难，因为在我的 Win7 Pro 开发机器上我可以测试和运行任何东西，但是当我尝试在简单的 Win7 Home 笔记本电脑上测试一些代码时，我发现权限被拒绝。这就引出了将 PrincipalPolicy 更改为“WindowsPrincipal”的问题，它不适用于所有 vista 和 Win7 用户，因为许多用户甚至不会成为管理员用户组的一部分。所以这个选项是没用的......坐在这台小型笔记本电脑上变得非常明显，这不是我需要的解决方案。

忽略以前的问题 - 我自己的研究已经完成，它们是不可行的。

问题 4：如何以编程方式临时在代码中冒充管理员？

4

1 回答 1

1

最简洁的答案是不。

似乎在我一直在那里进行的所有挖掘回合之后，似乎没有一种提升方法权限的程序化方式，因为 CAS 恭维 RBS，所以如果用户不属于正确的组。那么甚至访问管理员权限也没有意义，因为 rbs 告诉 cas 该用户不属于该组，因此请求被退回并且权限被拒绝。导致异常。

如果用户是您需要的组的一部分，即管理员，那么更改域 PrincipalPolicy 将为您提供一个临时解决方案，但它不适合不属于管理员用户组的用户。这就是上述解决方案崩溃的地方。

长答案是，将容易出现问题的代码发送到一个小的单独的 .exe 文件中并单独运行。

于 2010-08-07T17:55:48.367 回答