This isn't really for users. It is for developers like me.
Yes it is a security hole but again, it is a debugger.
The people who will be using it can all ssh into the server machine with
the same ID that the server process is running on.
In fact, this is quite normal.
As it is right now, we log into these machines and start an interactive
Python and use the bindings to debug things.
This works well most of the time but when you do that you need to start
another session of the application.
It is useful to run code interactively from within an actual client session
where something has gone wrong.
In any case.... I got this working with a rudimentary SWT Java client
(yuck, but the application is based on Eclipse).
Below is the code I used. It has a singleton interactive console object.
I sub-classed it and defined another method "process" which simply calls
the "push" method after wrapping stdout and stderr.
It returns anything that was printed to stdout, stderr, and the return
value of the "push" method.
So now from the client I can process one line at a time and it behaves much
like the real interactive console... you wouldn't even realize there is all
this client / server / WSDL / xml / https junk going on.
############ BEGIN CODE
import sys
from code import InteractiveConsole
class MyBuffer(object):
def __init__(self):
self.buffer = []
def write(self, data):
self.buffer.append(data)
def get(self):
ret = ''.join(self.buffer)
self.buffer = []
return ret
class MyInteractiveConsole(InteractiveConsole):
def __init__(self, *args, **kwargs):
InteractiveConsole.__init__(self, *args, **kwargs)
self.mb_out = MyBuffer()
self.mb_err = MyBuffer()
def process(self, s):
sys.stdout, sys.stderr = self.mb_out, self.mb_err
more = self.push(s)
sys.stdout, sys.stderr = sys.__stdout__, sys.__stderr__
return self.mb_out.get(), self.mb_err.get(), more
print 'creating new interactive console'
mic = MyInteractiveConsole()
On Fri, Aug 17, 2012 at 10:06 AM, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Aug 17, 2012 at 11:28 PM, Eric Frederich
> <eric.freder...@gmail.com> wrote:
> > Within the debugging console, after importing all of the bindings, there
> > would be no reason to import anything whatsoever.
> > With just the bindings I created and the Python language we could do
> > meaningful debugging.
> > So if I block the ability to do any imports and calls to eval I should be
> > safe right?
>
> Nope. Python isn't a secured language in that way. I tried the same
> sort of thing a while back, but found it effectively impossible. (And
> this after people told me "It's not possible, don't bother trying". I
> tried anyway. It wasn't possible.)
>
> If you really want to do that, consider it equivalent to putting an
> open SSH session into your debugging console. Would you give that much
> power to your application's users? And if you would, is it worth
> reinventing SSH?
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
