Python预加载为什么不起作用？

Question

在最初几个调用之后，使用函数interposition for open()与Python似乎不起作用。我怀疑Python正在进行某种初始化，或者有什么东西临时绕过了我的函数。在

在这里，open调用显然被钩住了：

$ cat a
hi
$ LD_PRELOAD=./libinterpose_python.so cat a
sandbox_init()
open()
hi

在这里，它在Python初始化期间发生一次：

^{pr2}$

这里根本不会发生这种情况，并且不会出现错误，表明文件句柄已删除写入权限：

$ LD_PRELOAD=./libinterpose_python.so python3 -c 'b = open("a", "w"); b.write("hi\n"); b.flush()'
sandbox_init()
sandbox_fini()

code是{a2}。使用make -f Makefile.interpose_python生成。在

给出了一个完整的解here。在

Answer 1

有open（）和open64（）函数，您可能需要重新定义这两个函数。在

Answer 2

通过在strace下运行python进程（可能不需要预加载），您应该能够发现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)

Answer 3

它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

The open64() function is a part of the large file extensions, and is equivalent to calling open() with the O_LARGEFILE flag.

运行未注释open64部分的示例代码可以得到：

^{pr2}$

它清楚地显示了Python的所有open调用，以及由于从调用中剥离write标志而传播的一些错误。在