[IronPython] Re strict imports

Leo Carbajal desleo at gmail.com
Mon Sep 1 07:58:38 CEST 2008

I hate bringing this issue up over and over again, but anyway, I'd rather
re-use one of these conversations. This CAS stuff is really driving me nuts,
moreso because it makes me feel dumber than a door nail to not understand
what's going on. I've got IPY 2.0 loading into a 'sandboxed' domain, and it
can run basic python calculations and stuff like print just fine, the moment
I try to have it interact with an object I pass in through globals though I
get a permission error where (it looks like to me) the act is asking for
nothing less than completely unrestricted access. Here's the error:

Unhandled Exception: System.Security.SecurityException: Request failed.
   at _stub_$6##6(Closure , CallSite , Object , CodeContext )
   at _stub_MatchCaller(Object , CallSite , Object[] )
   at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
site, T0 arg0, T1 arg1)
Scope , LanguageContext )
code, Scope scope)
   at System.Scripting.SourceUnit.Execute(Scope scope, ErrorSink errorSink)
   at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope)
   at Microsoft.Scripting.Hosting.ScriptRuntime.ExecuteFile(String path)
   at Microsoft.Scripting.Hosting.ScriptRuntime.ExecuteFile(String path)
   at IronPythonShell.Program.Main(String[] args) in
nPythonShell\Program.cs:line 49
The action that failed was: Demand
The type of the first permission that failed was:
The demand was for: <PermissionSet class="System.Security.PermissionSet"
version="1" Unrestricted="true"/>

The granted set of the failing assembly was:
<PermissionSet class="System.Security.PermissionSet" version="1">
<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib,
Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1" Read="B:\Code\IronPythonShell\IronPythonShell\bin\Debug\"
<IPermission class="System.Security.Permissions.ReflectionPermission,
mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1" Unrestricted="true"/>
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1" Unrestricted="true"/>

*The code looks like this:*
           Item item = new Item("Monkey");
            item.Value = 10;
            item.Type = ItemType.Misc;

            PermissionSet pset = new PermissionSet(PermissionState.None);
FileIOPermission(FileIOPermissionAccess.PathDiscovery |
FileIOPermissionAccess.Read, AppDomain.CurrentDomain.BaseDirectory));
            AppDomainSetup domainSetup = new AppDomainSetup();
            domainSetup.ApplicationBase =

            // create the sandboxed domain
            AppDomain sandbox = AppDomain.CreateDomain(
                "Sandboxed Domain",



            ScriptRuntime runtime = ScriptRuntime.Create(sandbox);
            runtime.Globals.SetVariable("Artifact", new


import Artifact
i = 200
while i > 0:
    i = i - 1
print "Done in the second verse. Yes?"
print Artifact.Name

Item and ScriptableItem are simple classes with only those two properties,
ScriptableItem inherits from MarshalByRefObject. The idea is that Item will
eventually be a very powerful class and ScriptableItem is a wrapper around
it to only provide access to certain portions of the class (IPY 1.1 didn't
do so well with obeying interfaces). I tried using
[EnvironmentPermissionAttribute(SecurityAction.LinkDemand, Unrestricted =
true)] on both of those classes, but it didn't work. CreateStrongName is a
method I pulled from this post:

The way I understand it, Microsoft.Scripting, Microsoft.Scripting.Core and
my own assembly should be given full trust when the sandbox domain is first
created so I'm at a complete loss. This code works fine, of course, if I
don't create the runtime in the domain.

A little light, or some more reference material, would be very helpful =\


On Mon, Aug 25, 2008 at 12:56 PM, Michael Foord
<fuzzyman at voidspace.org.uk>wrote:

> Dody Gunawinata wrote:
>> Ah, my knowledge is out of date then.
>> I think the more apt thread is here
>> http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2008-June/007523.html
> Yep - Dino confirming that sandboxing is one of the intended uses of
> IronPython and that it should work (and a link to a blog entry about why
> some sandboxing problems are very difficult - particularly server
> applications where you need to protect against DoS through CPU and memory
> over use).
> Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080901/87a93a52/attachment.html>

More information about the Ironpython-users mailing list