You aren't entirely wrong - .NET 2.0 RTM was missing functionality we needed (partial trust reflection emit) but we got that in SP1.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, June 30, 2008 9:17 AM To: Discussion of IronPython Subject: Re: [IronPython] restrict scripting access Cool. I *thought* that the reason IronPython required full trust was due to bugs in the CLR, and am delighted to hear that I'm wrong! Michael Dino Viehland wrote: > Yep, it sure is - that's the reason why we leave this work to the .NET > framework and avoid taking the burden upon ourselves :). > > There's nothing, other than bugs, in IronPython that prevents it from running > in partial trust - look at Silverlight where IronPython runs with no > permissions. There have been a few bugs which have prevented us from running > on the desktop CLR in partial trust - generally once we find them they're > easy to fix. Tomas fixed some of those when looking at getting IronRuby > running in partial trust and we'll take at look at the issues that block > IronPython as well when we start pushing on this. > > Once the bugs are gone hosts can either create a partial trust app domain or > simply Deny or PermitOnly permissions before calling into IronPython. The > user code would then only have access to the .NET functionality that your > security policy outlines. If you so wanted your own object model could be > fully trusted for when the user calls back into you. What enables this is > that IronPython its self runs 100% w/o any trust - it's marked > SecurityTransparent. So any actions that IronPython attempts to perform > require full demands upon the code calling into IronPython. You might need > to implement your own fully trusted host which handles access to the file > system but that should be trivial to do. > > This offers 100% security which is a nice guarantee to have. But many apps > might just need a "3 foot high wall" which their users are unlikely to jump > over and for those maybe getting rid of import clr and any available DLLs > will be sufficient. I'm not sure where we're currently prioritizing these > bugs so any feedback on how interesting these scenarios are would be helpful > :). > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo > Sent: Monday, June 30, 2008 7:04 AM > To: Discussion of IronPython > Subject: Re: [IronPython] restrict scripting access > > 2008/6/30 Rainer Worbis <[EMAIL PROTECTED]>: > >> is there a way to restrict access to objects or namespaces within a script? >> We use IronPython for providing scripting functionality within our .NET >> Application but would like to restrict access to certain functions. Has >> anybody information or a sample how to do that? >> > > Proper sandboxing is a difficult problem. Take a look at the following > post for a good overview. > > http://radix.twistedmatrix.com/2008/05/requirements-for-restricted-execution.html > > -- > Seo Sanghyeon > _______________________________________________ > 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 > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ _______________________________________________ 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
