In article <9409261736.AA20116=guido@voorn.cwi.nl> Guido.van.Rossum@cwi.nl writes:
>
>A large improvement over this might be to let the host code provide a
>"guard" function implemented in Python -- when a potentially dangerous
>built-in function is about to be called (this can be checked by
>call_builtin) the guard is called with the function name and the
>argument list. The guard can then check whatever it wants and return
>true or false (or perhaps raise an exception instead of returning
>false). It may even be possible to to let the guard return an
>alternative outcome to be substituted. Such a guard could also be
>applied for some functionality that's not implemented as functions,
>like 'import'.
>
>A concrete proposal for an interface would be to add a flag to the
>"methodlist" table of each module to indicate which functions are
>unsafe (let the default be safe -- by far the majority of functions
>are probably safe), and to add a built-in function
>
> guarded_exec(string, globals, locals, guard)
Sounds good. Perhaps you should also allow the applications programmer
to specify a collection of functions/methods that s/he claims to be
safe which the guarded_exec will run in unguarded mode. For example,
I might want to allow my students to be able to submit assignments,
stored to a file in my directory, once I've verified their identity -- the
verification, checking, and writing could be implemented by me (the A.P.)
as a function and I could ask the guard to trust calls to that
function. This would allow A.P.'s like me to make horrible mistakes,
but if this isn't available we'll be tempted to use unprotected python and
make even worse mistakes.
Of course, guarded_exec should allow defs and input-level assignments
only within a special local module, to prevent my student from
redefining functions or globals, or otherwise messing up the server process.
In fact, perhaps Python should only provide "really basic" services to
untrusted code and require the A.P. (me) to explicitly specify all
"non-basic" function/method calls which are allowed. This puts all
the responsibility on the A.P., so they can't whine at you if you
(Guido or whoever) accidentally misjudge a dangerous function as safe.
More concretely, maybe replace the "guard" with a "trusted_functions"
structure and have guarded_exec only execute "core" python that
restricts assignments and defs and only allows function/method calls
to code archived in "trusted_functions".
And yes, I do think something like this would be an excellent idea.
Aaron Watters
Department of Computer and Information Sciences
New Jersey Institute of Technology
University Heights
Newark, NJ 07102
phone (201)596-2666
fax (201)596-5777
home phone (908)545-3367
email: aaron@vienna.njit.edu