.NET DLR and SecurityException's

Question

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.

score 2 · Accepted Answer · answered Apr 13 '11 at 12:58

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.

Sometimes a second opinion like this post is all it needs to find the solution. Turns out my assembly (that `someobject` originates from, i my example) was missing the token "AllowPartiallyTrustedCallersAttribute". I'm annoyed with myself that I didn't check and double-check this sooner. — nbevans, Apr 13 '11 at 13:44

.NET DLR and SecurityException's

1 Answers1