Hi, Keith,
Von: Keith Rome [mailto:r...@wintellect.com]
> Take a look at the PlatformAdaptationLayer class. You can create your own and
> plug it in to the runtime. This might provide the hooks you are looking for.
> In particular, you should be able to override the LoadAssembly() and
> LoadAssemblyFromPath() methods to block anything that isn't whitelisted for
> your host environment.
I did think about that method, but as far as I can see, I won't be able to
prevent an AddReference("AssemblyName") for an assembly which is already loaded
in the current AppDomain.
I'd be happy to be proved wrong on this, however. :-)
Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | kr...@wintellect.com
www.wintellect.com
From: Ironpython-users
[mailto:ironpython-users-bounces+rome=wintellect....@python.org] On Behalf Of
Markus Schaber
Sent: Wednesday, October 17, 2012 6:09 AM
To: Discussion of IronPython
Subject: [Ironpython-users] Restrict referencing of assemblies in hosted
environment
Hello,
We're using IronPython as a hosted script engine in our application.
Now, we want to restrict the assemblies a user can reference from its python
script,
Currently, we just forbid "import clr", by wrapping the import() method, but
this is a bit harsh, and the side-effects are a little bit to strong (e. G. it
causes "import minidom.py" to fail...)
However, there seems to be no event or other hook available for AddReference
which I could use. It may be possible to add an AssemblyLoading event to the
ScriptDomainManager in Microsoft.Scripting.Runtime, which allows to cancel the
assembly loading by throwing an exception. Would such a patch be accepted
upstream?
An alternative (not-so-elegant) idea is that I just wrap all the AddReference()
& Co calls inside the clr module, but there may be a more elegant way.
Isolating Ironpython in its own AppDomain is not an option, as this would
require major rework of our Scripting API implementation, and also break
backwards compatibility for 3rd party plugins which contribute API for the
scripts.
(We don't need a 100% waterproof method - we know that the user can use
cTypes, System.Reflection, or whatever to circumvent everything - we just want
to restrict the obvious ways to access some APIs we consider to be internal.)
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax
+49-831-54031-50
Email: m.scha...@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade
register: Kempten HRB 6186 | Tax ID No.: DE 167014915
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users
