I will have to try it out, then. At the very worst I can always set up the shell and then apply the proper permissions (or lack thereof) later when its supported, I doubt my own project will be going live any time soon anyway so a little leeway in testing is no big deal.
Now to wrap my head around the new hosting API, maybe a third read through on the docs will help. =\ 2008/8/1 Dino Viehland <[EMAIL PROTECTED]> > One thing I'll point out is in 2.0 we've done a bunch of work to make > working with a remote app domain pretty easy. You can create the > ScriptRuntime in the remote domain and get back a ScriptEngine which lives > in the remote domain. All of the calls on the hosting APIs use serializable > / MBRO objects so that they're safe to use from a remoting standpoint. Also > ObjectOperations provides versions of the APIs that work with ObjectHandle's > instead of raw objects. So all you have to watch out for is making sure the > objects you're sending across the wire are MBRO or Serializable. > > > > That being said we still have a few bugs which prevent you from creating a > completely untrusted domain and loading the ScriptRuntime over there. Those > should be getting resolved fairly soon though but won't be in 2.0 Beta 4 L > . > > > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Leo Carbajal > *Sent:* Friday, August 01, 2008 5:29 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Sandboxing using AppDomains > > > > I had seen that series, though I admit I missed the posts on not using > deny. Still rather leaves me in a bind, I guess I'll just have to see how > passing object references works through an AppDomain. > > --- > LC > > 2008/7/31 Han Kejing <[EMAIL PROTECTED]> > > Hi, Leo, > > Maybe follows document is helpful for you. > > http://blogs.msdn.com/shawnfa/archive/2005/08/08/449050.aspx > > > > PermissionSet.Deny is not safe. User code may use PermissionSet.Assert to > get the power easily. > > > > > > > > ---------------------------------------------------------------- > > Follow my heart > > *Colin Han @* *MultiRow Developer Team (A Strong Team)* > > > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Leo Carbajal > *Sent:* 2008年7月31日 10:07 > *To:* [email protected] > *Subject:* [IronPython] Sandboxing using AppDomains > > > > Howdy all, > > I know this is a topic that comes up again and again but I was hoping I > could get a bit of understanding from someone. > > So, like many others, I'm looking to get IPy to work in a relatively safe > environment. My application is a game-server and exposes many entry points > for user created scripts to essentially extend the game's reactions. Because > these scripts are open to the public I need to be sure that it cannot do > nasty things like delete all the script files, my app or anything else on > the server, access my other non-exposed functions, etc. > > Anyway, so after reading up a little on AppDomains it sounds like running > IPy through one could be a little prohibitive. I'm not really passing > value-types to work on, I'm allowing the scripts to directly access and > modify the objects themselves. I guess I'm not sure if what I want to do > will even work, and I haven't had a chance to put together a test. The use > of scripting in the application is extensive so I worry that I may have to > scale back - or risk having someone one day using a little reflection to > snoop out my app's API and calling functions that the scriptShell was never > intended to be able to use. > > Would using permission.Deny for the permissions I want to disallow be > enough to keep things safe? I.E. something like: > > //elsewhere > private static PermissionSet ps = new PermissionSet(PermissionState.None); > ps.AddPermission(new > SecurityPermission(SecurityPermissionFlag.Execution)); > ps.AddPermission(new > FileIOPermission(FileIOPermissionAccess.PathDiscovery | > FileIOPermissionAccess.Read, Path)); > > public static void PlayFirstFile(Item caller) > { > locals.Add("Artifact", new ScriptableItem(caller)); > string script = (Path + "script.py"); > ps.Deny(); > engine.ExecuteFile(script, engine.DefaultModule, locals); > locals.Clear(); > } > > ScriptableItem, by the way, is a class wrapper to hide private methods in > Item after I found out that passing something as a template doesn't work to > occlude methods\properties I don't want called. =\ > > I'm a little lost when it comes to all this security stuff, I could really > use a bit of explanation and would really appreciate any help that can come > this way. > > I'm using IronPython 1.1.2 as I haven't had the chance to sit down and > really play with 2.0, it seems a bit more convoluted to set-up but thats > entirely a from-the-outside perspective at the moment. > > --- > LC > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
