By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,957 Members | 1,960 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,957 IT Pros & Developers. It's quick & easy.

injecting functions into a python sandbox within a python program

P: n/a
I have a large Python 2.5 program that I want my users to be able to
"extend" using a Python script. However, I want their script to run in a
sandbox within the overall program so that they only have access to the
rest of the program via a single simple interface. Note that this is not
meant to be a real anti-hacker type security sandbox - just "help them
to avoid shooting themselves in the foot" type security.

So I created a single object that has the interface that I want them to
access. I call their script via "exec" passing the single interface
object in the "globals" parameter to exec. It (conceptually) looks like
this:

i = Interface()
glob = { 'i': i }
exec script in glob

Then they can call i.whatever() from within their script. This all works
fine.

Now, what I want to do is provide some "helper" functions for them to
use in the script. These functions still only access the rest of the
program via 'i'. They just wrap some of the interface functions to make
life easier for the user. My current solution is to prepend these
functions onto the start of the script. I.e.

helperFuncs = """
def f1(): i.whatever()
"""

exec helperFuncs + "\n" + script.read() in glob

This works but doesn't seem very elegant.

I've tried defining the helper funcions in my caller and passing them
through the globals i.e.

def f1(): i.whatever()
glob = { 'i': i, 'f1': f1 }
exec script in glob

The problem here is that the functions don't have access to the global
variable 'i'. I need to use that object instance since it has other
functionality that is required to interface to the rest of the program.

I'm sure that this is simple to get around for a Python expert (which I
am not!). Does anybody have any ideas? Any alternate approach?

Thanks in advance for any assistance,
Graham
Jan 9 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Graham Menhennitt a écrit :
I have a large Python 2.5 program that I want my users to be able to
"extend" using a Python script. However, I want their script to run in a
sandbox within the overall program so that they only have access to the
rest of the program via a single simple interface. Note that this is not
meant to be a real anti-hacker type security sandbox - just "help them
to avoid shooting themselves in the foot" type security.

So I created a single object that has the interface that I want them to
access. I call their script via "exec" passing the single interface
object in the "globals" parameter to exec. It (conceptually) looks like
this:

i = Interface()
glob = { 'i': i }
exec script in glob

Then they can call i.whatever() from within their script. This all works
fine.

Now, what I want to do is provide some "helper" functions for them to
use in the script. These functions still only access the rest of the
program via 'i'. They just wrap some of the interface functions to make
life easier for the user. My current solution is to prepend these
functions onto the start of the script. I.e.

helperFuncs = """
def f1(): i.whatever()
"""

exec helperFuncs + "\n" + script.read() in glob

This works but doesn't seem very elegant.
Indeed.
If all your helper functions are really methods of the Interface
instance, you may try this instead (NB : not tested):

glob = {
'i': i,
'f1': i.whatever,
}
exec script in glob

HTH
Jan 9 '07 #2

P: n/a
Bruno Desthuilliers wrote:
If all your helper functions are really methods of the Interface
instance, you may try this instead (NB : not tested):

glob = {
'i': i,
'f1': i.whatever,
}
exec script in glob
Bruno,

Thanks for replying.

Some of the functions are as simple as that so I can do as you
described. Some are more complicated so it doesn't work. For now I'll
stick with the prepending.

Thanks,
Graham
Jan 11 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.