How to permanently remove __import__?

martin z pxtl at hotmail.com
Wed Jun 18 10:14:01 EDT 2003


"Peter Hansen" <peter at engcorp.com> wrote in message
news:3EEF970C.4630A21 at engcorp.com...
> martin z wrote:
> >
> > Rexec tried to do too much is my understanding - I'm just redirecting
Import
> > into a new (custom) filesystem.  I haven't looked at Bastion.
>
> So you aren't concerned that anyone will be able to find a leftover
reference
> to the original import that might have been stored in the locals of a
function
> or method somewhere?  Or that they'll simply be able to override yours
with
> a new one that basically restores the original functionality?  Your
comment
> about "under any circumstances" sounded extreme, but maybe you aren't
quite
> so concerned about such things as you sounded. :-)

No, I am so concerned.  What I meant by "rexec tried to do too much" was
that rexec
still allowed some access to the traditional filesystem.  It had this
bizarre, ambiguous concept
that "I'm only going to allow modules that aren't dangerous".  That's what I
meant by "too much".

I do want to totally disable the regular import command.   Actually, more
specifically, I don't want
the user accessing the filesystem in any way whatsoever at all.  I want to
wholly disable standard access
to the filesystem.  The app I'm working on will be used in a network
environment.  The custom filesystem
has a complicated package-management and distribution system that keeps the
system well-appraised of
what is and will be available - and is synchronizable with other machines.
The standard (local) filesystem
is comparatively dangerous.  If users wrote scripts that used the standard
filesystem instead of the custom
filesystem, it would break things, and it would be untrusted.

So, I need to disable access to the standard filesystem.  I see two options
on how to do this: disable/override
all of the built-in functions that access the filesystem (the imp module,
open, etc) or somehow get rid of the
filesystem "under the hood".

This is what I meant by "too much".  I have no ambiguous concept of
"potentially dangerous code" - I just don't want
the user getting at the files.






More information about the Python-list mailing list