.NET DLR 和 SecurityException
DLR 需要哪些强制 PermissionSet
项目才能正常运行?
我们已在沙盒脚本环境中启用了 DLR。但是像下面这样的一些代码......
dynamic foo = someobject
foo.FooBar();
只会导致抛出一个相当模糊且“未完成”的异常,如下所示:
System.Security.SecurityException: Request failed.
at CallSite.Target(Closure , CallSite , Object )
at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid1[T0](CallSite site, T0 arg0)
at AcmeCorp.AcmeRocket.Workflow.Scripting.Assemblies.WorkflowScriptImplementation.Test()
at AcmeCorp.AcmeRocket.Workflow.Scripting.Assemblies.WorkflowScriptImplementation.__action_activity_4397110c5d7141a6802a070d3b942b77()
--- End of inner exception stack trace ---
at AcmeCorp.AcmeRocket.Workflow.Scripting.WorkflowScriptProxy.Invoke(String method_name)
at AcmeCorp.AcmeRocket.Workflow.Execution.Executors.ActionActivityExecutor.Execute(WorkflowInstance wi, ActionActivity activity)
at AcmeCorp.AcmeRocket.Workflow.Execution.ActivityExecutorBase.Execute(WorkflowInstance wi, Activity activity)
at AcmeCorp.AcmeRocket.Workflow.Execution.WorkflowExecutor.ExecuteActivity(WorkflowInstance wi, Activity activity)
at AcmeCorp.AcmeRocket.Workflow.Execution.WorkflowExecutor.Execute(WorkflowInstance wi, Nullable`1 branch_index)
通常 SecurityException
包含大量详细信息,精确指定哪些异常权限导致它失败,但在这种情况下我们没有得到它 - 非常烦人。
PS:如果我使用临时授予 PermissionSet(PermissionState.Unrestricted) 的沙箱运行相同的测试,那么问题就会消失。但显然我们确实希望将其锁定为 DLR 所需的非常特定的权限集。
PPS:当前(失败)PermissionSet 创建如下:
var ps = new PermissionSet(PermissionState.None);
ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
ps.AddPermission(new ReflectionPermission(ReflectionPermissionFlag.RestrictedMemberAccess));
谢谢。
What are the mandatory PermissionSet
items that the DLR requires in order to function correctly?
We've enabled the DLR in our sandboxed scripting environment. But some code like the following...
dynamic foo = someobject
foo.FooBar();
... just results in a rather vague and "unfinished"-looking exception being thrown, as follows:
System.Security.SecurityException: Request failed.
at CallSite.Target(Closure , CallSite , Object )
at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid1[T0](CallSite site, T0 arg0)
at AcmeCorp.AcmeRocket.Workflow.Scripting.Assemblies.WorkflowScriptImplementation.Test()
at AcmeCorp.AcmeRocket.Workflow.Scripting.Assemblies.WorkflowScriptImplementation.__action_activity_4397110c5d7141a6802a070d3b942b77()
--- End of inner exception stack trace ---
at AcmeCorp.AcmeRocket.Workflow.Scripting.WorkflowScriptProxy.Invoke(String method_name)
at AcmeCorp.AcmeRocket.Workflow.Execution.Executors.ActionActivityExecutor.Execute(WorkflowInstance wi, ActionActivity activity)
at AcmeCorp.AcmeRocket.Workflow.Execution.ActivityExecutorBase.Execute(WorkflowInstance wi, Activity activity)
at AcmeCorp.AcmeRocket.Workflow.Execution.WorkflowExecutor.ExecuteActivity(WorkflowInstance wi, Activity activity)
at AcmeCorp.AcmeRocket.Workflow.Execution.WorkflowExecutor.Execute(WorkflowInstance wi, Nullable`1 branch_index)
Normally SecurityException
's include a host of detail specifying precisely which permissions caused it to fail, but in this case we are not getting that - very annoying.
PS: If I run the same test with our sandbox temporarily granted a PermissionSet(PermissionState.Unrestricted)
then the problem goes away. But obviously we really want to lock it down to the very specific set of permissions that the DLR requires.
PPS: The current (failing) PermissionSet is created as follows:
var ps = new PermissionSet(PermissionState.None);
ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
ps.AddPermission(new ReflectionPermission(ReflectionPermissionFlag.RestrictedMemberAccess));
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您没有获得更详细的安全异常的原因是,它是在具有受限 CAS 权限的上下文中读取的。如果您在完全可信的上下文中调用其 ToString 方法,您可以阅读完整的异常详细信息。
也就是说,我无法在简单的沙盒 AppDomain 场景中重现相同的问题,因此我想知道您的异常是否确实是由于 DLR 使用造成的。如果您尝试在相同权限集下的强类型目标实例上调用相同方法,会发生什么情况?
例如,如果调用的方法具有针对不受限制的权限集的 LinkDemand,我可以重现类似的异常。尽管调用堆栈不同,但无论是针对动态变量还是针对强类型变量的调用,都可以看到此问题。
The reason you're not getting a more detailed security exception is that it is being read in a context that has restricted CAS permissions. You can read the full exception details if you invoke its ToString method in a fully trusted context.
That said, I am unable to reproduce the same problem in a simple sandboxed AppDomain scenario, so I'm wondering if your exception is really due to DLR use. What happens if you attempt to invoke the same method on a strongly typed target instance under the same permission set?
For example, I can repro a similar exception if the invoked method has a LinkDemand for an unrestricted permission set. This problem can be seen, albeit with a different call stack, regardless of whether the invocation against a dynamic or strongly typed variable.