.NET DLR and SecurityException

Question

What are the required PermissionSet elements required by the DLR for proper operation?

We included DLR in the sandboxed scripting environment. But some code is similar to the following ...

 dynamic foo = someobject foo.FooBar(); 

... just leads to a rather vague and "incomplete" observing exception 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) 

Typically, a SecurityException includes many details that determine exactly which permissions led to its failure, but in this case we do not get this - it is very annoying.

PS: If I run the same test with our sandbox temporarily provided by PermissionSet(PermissionState.Unrestricted) , then the problem will disappear. But, obviously, we really want to block it to the very specific set of permissions required by the DLR.

PPS: the current (failed) PermissionSet is created as follows:

 var ps = new PermissionSet(PermissionState.None); ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution)); ps.AddPermission(new ReflectionPermission(ReflectionPermissionFlag.RestrictedMemberAccess)); 

Thanks.

Answer 1

The reason you don't get a more detailed security exception is because it is read in a context that restricts CAS permissions. You can read the full details of the exception if you call its ToString method in a fully trusted context.

However, I cannot reproduce the same problem in a simple isolated AppDomain script, so I wonder if your exception is really related to using DLR. What happens if you try to call the same method on a strongly typed target instance with the same permission set?

For example, I can throw a similar exception if the called method has LinkDemand for an unlimited set of permissions. This problem can be seen, albeit with a different call stack, regardless of whether the call is a dynamic or strongly typed variable.