Syscall Proxying in Python
Hi, We embbeded Python 2.0.1 in our product a few years ago and we'd like to upgrade to Python 2.4.1. This was not a simple task, because we needed to execute syscalls on a remote host. We modified Python's source code in severall places to call our own versions of some functions. For example, instead of calling fopen(...), the source code was modified to call remote_fopen(...), and the same was done with other libc functions. Socket functions where hooked too (we modified socket.c), Windows Registry functions, etc.. There are some syscalls that we don't want to execute remotely. For example when importing a module. That has to be local, and we didn't modified that. Python scripts are executed locally, but syscalls are executed on a remote host, thus giving the illusion that the script is executing on the remote host. As I said before, we're in the process of upgrading and we don't want to make such unmaintainable changes to Python's code. We'd like to make as few changes as possible. The aproach we're trying this time is far less intrusive: We'd like to link Python with special libraries that override those functions that we want to execute remotely. This way the only code that has to be changed is the one that has to be executed locally. I wrote this mail to ask you guys for any useful advice in making this changes to Python's core. The only places I figure out right now that have to execute locally all the time are import.c and pythonrun.c, but I'm not sure at all. Maybe you guys figure out another way to achieve what we need. Thanks in advance. -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES Florida 141 - 2º cuerpo - 7º piso C1005AAC Buenos Aires - Argentina Tel/Fax: (54 11) 5032-CORE (2673) http://www.corest.com
On Mon, 2005-08-01 at 10:36, Gabriel Becedillas wrote:
Hi, We embbeded Python 2.0.1 in our product a few years ago and we'd like to upgrade to Python 2.4.1. This was not a simple task, because we needed to execute syscalls on a remote host. We modified Python's source code in severall places to call our own versions of some functions. For example, instead of calling fopen(...), the source code was modified to call remote_fopen(...), and the same was done with other libc functions. Socket functions where hooked too (we modified socket.c), Windows Registry functions, etc..
Wow... you guys sure did it the hard way. If you had done it at the Python level, you would have had a much easier time of both implementing and updating it. As an example, have a look at my osVFS stuff. This is a replacement for the os module and open() that tricks Python into using a virtual file system; http://minkirri.apana.org.au/~abo/projects/osVFS -- Donovan Baarda <abo@minkirri.apana.org.au>
Donovan Baarda wrote:
On Mon, 2005-08-01 at 10:36, Gabriel Becedillas wrote:
Hi, We embbeded Python 2.0.1 in our product a few years ago and we'd like to upgrade to Python 2.4.1. This was not a simple task, because we needed to execute syscalls on a remote host. We modified Python's source code in severall places to call our own versions of some functions. For example, instead of calling fopen(...), the source code was modified to call remote_fopen(...), and the same was done with other libc functions. Socket functions where hooked too (we modified socket.c), Windows Registry functions, etc..
Wow... you guys sure did it the hard way. If you had done it at the Python level, you would have had a much easier time of both implementing and updating it.
As an example, have a look at my osVFS stuff. This is a replacement for the os module and open() that tricks Python into using a virtual file system;
Hi, thanks for your reply. The problem I see with the aproach you're sugesting is that I have to rewrite a lot of code to make it work the way I want. We allready have the syscall proxying stuff with an stdio layer on top of it. I should have to rewrite some parts of some modules and use my own versions of stdio functions, and that is pretty much the same as we have done before. There are also native objects that use stdio functions, and I should replace those ones too, or modules that have some native code that uses stdio, or sockets. I should duplicate those files, and make the same kind of search/replace work that we have done previously and that we'd like to avoid. Please let me know if I misunderstood you. Thanks again. -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES Florida 141 - 2º cuerpo - 7º piso C1005AAC Buenos Aires - Argentina Tel/Fax: (54 11) 5032-CORE (2673) http://www.corest.com
On Tue, 2005-08-02 at 11:59, Gabriel Becedillas wrote:
Wow... you guys sure did it the hard way. If you had done it at the Python level, you would have had a much easier time of both implementing and updating it. [...] Hi, thanks for your reply. The problem I see with the aproach you're sugesting is that I have to rewrite a lot of code to make it work the way I want. We allready have
Donovan Baarda wrote: [...] the syscall proxying stuff with an stdio layer on top of it. I should have to rewrite some parts of some modules and use my own versions of stdio functions, and that is pretty much the same as we have done before. There are also native objects that use stdio functions, and I should replace those ones too, or modules that have some native code that uses stdio, or sockets. I should duplicate those files, and make the same kind of search/replace work that we have done previously and that we'd like to avoid. Please let me know if I misunderstood you.
Nope... you got it all figured out. I guess it depends on what degree of "proxying" you want... I thought there was some stuff you wanted re-directed, and some you didn't. The point is, you _can_ do this at the Python level, and you only have to modify Python code, not C Python source. However, if you want to proxy everything, then the glib wrapper is probably the best approach, provided you really want to code in C and have your own Python binary. -- Donovan Baarda <abo@minkirri.apana.org.au>
participants (2)
-
Donovan Baarda -
Gabriel Becedillas