使用Python的open()
函数插入在前几次调用后似乎不起作用。我怀疑Python正在进行某种初始化,或者某些东西暂时绕过了我的功能。
此处open
来电显然已被勾解:
$ cat a
hi
$ LD_PRELOAD=./libinterpose_python.so cat a
sandbox_init()
open()
hi
这在Python初始化期间发生一次:
$ LD_PRELOAD=./libinterpose_python.so python
sandbox_init()
Python 2.7.2 (default, Jun 12 2011, 20:20:34)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
open()
>>>
sandbox_fini()
这里根本没有发生,并且没有错误表明文件句柄已删除写权限:
$ LD_PRELOAD=./libinterpose_python.so python3 -c 'b = open("a", "w"); b.write("hi\n"); b.flush()'
sandbox_init()
sandbox_fini()
code是here。使用make -f Makefile.interpose_python
构建。
给出了完整的解决方案here。
答案 0 :(得分:8)
有open()和open64()函数,您可能需要重新定义它们。
答案 1 :(得分:1)
你应该能够通过在strace
下运行它来找出你的python进程实际正在做什么(可能没有你的预加载)。
我的python3.1(在AMD64上)似乎确实使用了open
:
axa@ares:~$ strace python3.1 -c 'open("a","r+")'
...
open("a", O_RDWR) = -1 ENOENT (No such file or directory)
答案 2 :(得分:1)
它turns out有一个open64()
函数:
$ objdump -T /lib32/libc.so.6 | grep '\bopen'
00064f10 g DF .text 000000fc GLIBC_2.4 open_wmemstream
000cc010 g DF .text 0000007b GLIBC_2.0 openlog
000bf6d0 w DF .text 000000b6 GLIBC_2.1 open64
00094460 w DF .text 00000055 GLIBC_2.0 opendir
0005f9b0 g DF .text 000000d9 GLIBC_2.0 open_memstream
000bf650 w DF .text 0000007a GLIBC_2.0 open
000bf980 w DF .text 00000081 GLIBC_2.4 openat
000bfb90 w DF .text 00000081 GLIBC_2.4 openat64
open64()函数是大文件扩展名的一部分,相当于使用O_LARGEFILE标志调用open()。
运行未注释open64
部分的示例代码会产生:
$ LD_PRELOAD=./libinterpose_python.so python3 -c 'b = open("a", "w"); b.write("hi\n"); b.flush()'
sandbox_init()
open64()
open64()
open64()
Traceback (most recent call last):
File "<string>", line 1, in <module>
open64()
open64()
open64()
open64()
open64()
open64()
open64()
IOError: [Errno 9] Bad file descriptor
sandbox_fini()
其中清楚地显示了所有Python的open
调用,以及由于写入标记从调用中删除而导致的一些传播错误。