[Python-Dev] rexec.py unuseable

Luke Kenneth Casson Leighton lkcl at lkcl.net
Mon Dec 15 12:31:56 EST 2003


i tried to reuse some code that i wrote for a project back when
python 2.0 and 2.1 were in use.

i must be about the only person in existence who wrote some code
that uses - and totally relies on - the rexec.py module.

what that code does (did) was to provide a database-based
method of running restricted programs for use to monitor and
manage remote servers.

i.e. it became in effect a distributed python operating system.

what happened was that the name of a python script, its
arguments, a relevant ip address and the server on which the
script was to be run were all entered into a database table,
and the server picked that up, loaded the script and its
arguments from the database and then ran the script, which
usually involved contacting the remote ip address.

so, not only was rhooks used to overload "import" such that
libraries used by scripts in the database could _also_ be
loaded from the database, but rexec.py was also used to restrict
what functions could be accessed.

i was quite happy with rexec.py as it stood.

it was the c++ functional equivalent of the "protected" convention
for c++ classes.

at the time that i tried to reuse the code, i discovered the lovely
"this module is broken in python 2.2 and 2.3" message.

well, uhm, if it's broken, why hasn't it been reverted to the 2.0
code?

i noted, some time about a year ago, that someone attempted to drill
down the rexec security into sub-modules.

i.e. they attempted to add the c++ functional equivalence of
the "private" convention for c++ classes.

consequently, a number of routines that wrote to files that i had
DELIBERATELY wrapped and made available to first-level rexec-restricted
library routines, e.g. the logging functions which output debug
information to log files, suddenly stopped working.

why?  whereas before, the debug routine could be called directly
but the write operation could not, because of the drill-down
effect, all of a sudden the write operation, as called _by_
the debug routine, is now restricted in the 2.1 (or early 2.2)
code, and my debug library routine now doesn't work, nor indeed
does anything else.


the thing is that the functionality of the python 2.0 rexec.py was
_exactly_ as i would have expected it to be, and it was working
_perfectly_ according to my expectations of that code.

i therefore believe that the attempts to take rexec one step further,
aka a "drill-down" effect, by making all functions that rexec functions
import _also_ restricted, to have been a mistake.

or, at least, not carefully thought out.

if such additional restrictions are to be added, i believe that they
should be added as a user-configureable parameter (e.g. named
recursive-restrict)

_please_ could the functionality of rexec.py be restored to python 2.0 
functionality, with the "rexec.py is broken" message only coming
up when the suggested-named parameter "recursive-restrict" is set.

maybe then i can consider reviving that code and re-releasing it,
because at the moment it's totally going to waste.

many many thanks,

l.


-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
then expecting someone to call you (and to be able to call you).
--
every day, people send out email expecting it to be received
without being tampered with, read by other people, delayed or
simply - without prejudice but lots of incompetence - destroyed.
--
please therefore treat email more like you would a CB radio
to communicate across the world (via relaying stations):
ask and expect people to confirm receipt; send nothing that
you don't mind everyone in the world knowing about...




More information about the Python-Dev mailing list