我有一个项目，旨在为大量虚拟主机（超过10k个虚拟主机）运行php-cgi chrooted，每个虚拟主机都有自己的chroot，在Ubuntu Lucid x86_64下。我希望避免在每个chroot内创建必要的环境，例如/dev/null、/dev/zero、locales、icons等等，以及可能被php模块需要但认为它们在chroot外运行的任何其他内容。
目标是使php-cgi在chroot内运行，但允许其访问chroot外的文件，只要这些文件（对于大多数文件）以只读模式打开，并且在允许列表中（/dev/log、/dev/zero、/dev/null、本地环境变量的路径等等）。
显然的方法似乎是创建（或使用已存在的）内核模块，该模块可以挂钩和重定向受信任的open()路径，超出chroot之外。但我认为这不是最简单的方法：
相反，我目前正在尝试一种用户空间解决方案：使用LD_PRELOAD挂钩libc函数，在大多数情况下都能很好地运行，并且实现起来非常快，但是我遇到了一个问题，无法独自解决。(想法是与在chroot之外运行的守护进程通信，并使用ioctl SENDFD和RECVFD获取文件描述符)。
当我调用syslog()（没有先调用openlog()）时，syslog()会调用connect()来打开文件。
例如：
到目前为止，我尝试挂钩libc的connect()函数，但没有成功。我还尝试在我的preload库的_init()函数中放置一些dlopen()标志来测试是否有一些标志可以使其工作，但也没有成功。
以下是我preload库的相关代码：
当然，我可以通过自己进行openlog()来完全跳过这个特定的问题，但我猜我会在一些其他函数中遇到相同类型的问题。
我真的不明白为什么openlog_internal不使用动态符号重定位来调用__connect()，如果使用简单的LD_PRELOAD机制是否可能挂钩此__connect()调用。
我看到它可以完成的其他方式：
我的谷歌搜索与“hook syscalls”相关，发现了很多关于LSM的参考资料，但它似乎只允许ACL回答“是”或“否”，而不允许重定向open()路径。
谢谢阅读。
显然的方法似乎是创建（或使用已存在的）内核模块，该模块可以挂钩和重定向受信任的open()路径，超出chroot之外。但我认为这不是最简单的方法：
- 我从未做过内核模块，因此无法正确评估难度。
- 似乎有多个系统调用来挂钩文件“打开”（打开、连接、mmap...），但我想与文件打开相关的所有内容都有一个共同的内核函数。
相反，我目前正在尝试一种用户空间解决方案：使用LD_PRELOAD挂钩libc函数，在大多数情况下都能很好地运行，并且实现起来非常快，但是我遇到了一个问题，无法独自解决。(想法是与在chroot之外运行的守护进程通信，并使用ioctl SENDFD和RECVFD获取文件描述符)。
当我调用syslog()（没有先调用openlog()）时，syslog()会调用connect()来打开文件。
例如：
folays@phenix:~/ldpreload$ strace logger test 2>&1 | grep connect
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
connect(1, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0
到目前为止，我尝试挂钩libc的connect()函数，但没有成功。我还尝试在我的preload库的_init()函数中放置一些dlopen()标志来测试是否有一些标志可以使其工作，但也没有成功。
以下是我preload库的相关代码：
void __attribute__((constructor)) my_init(void)
{
printf("INIT preloadz %s\n", __progname);
dlopen(getenv("LD_PRELOAD"), RTLD_NOLOAD | RTLD_DEEPBIND | RTLD_GLOBAL |
RTLD_NOW);
}
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
printf("HOOKED connect\n");
int (*f)() = dlsym(RTLD_NEXT, "connect");
int ret = f(sockfd, addr, addrlen);
return ret;
}
int __connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
printf("HOOKED __connect\n");
int (*f)() = dlsym(RTLD_NEXT, "connect");
int ret = f(sockfd, addr, addrlen);
return ret;
}
但是标准C库的connect()函数仍然优先于我的函数：
folays@phenix:~/ldpreload$ LD_PRELOAD=./lib-preload.so logger test
INIT preloadz logger
[...] no lines with "HOOKED connect..." [...]
folays@phenix:~/ldpreload$
查看syslog()的代码（apt-get source libc6, glibc-2.13/misc/syslog.c），它似乎调用openlog_internal，后者又调用__connect()，在misc/syslog.c的第386行：
if (LogFile != -1 && !connected)
{
int old_errno = errno;
if (__connect(LogFile, &SyslogAddr, sizeof(SyslogAddr))
== -1)
{
objdump向我展示了libc的动态符号表中的connect和__connect：
folays@phenix:~/ldpreload$ objdump -T /lib/x86_64-linux-gnu/libc.so.6 |grep -i connec
00000000000e6d00 w DF .text 000000000000005e GLIBC_2.2.5 connect
00000000000e6d00 w DF .text 000000000000005e GLIBC_2.2.5 __connect
但是在动态重定位项中没有连接符号，所以我猜这就解释了为什么我无法成功覆盖openlog_internal()使用的connect()函数，它可能不使用动态符号重定位，而且可能在硬件中具有__connect()函数的地址（一个相对-fPIC偏移量？）。
folays@phenix:~/ldpreload$ objdump -R /lib/x86_64-linux-gnu/libc.so.6 |grep -i connec
folays@phenix:~/ldpreload$
connect是__connect的弱别名：
eglibc-2.13/socket/connect.c:weak_alias (__connect, connect)
gdb仍然能够在libc的connect符号上设置断点：
folays@phenix:~/ldpreload$ gdb logger
(gdb) b connect
Breakpoint 1 at 0x400dc8
(gdb) r test
Starting program: /usr/bin/logger
Breakpoint 1, connect () at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
in ../sysdeps/unix/syscall-template.S
(gdb) c 2
Will ignore next crossing of breakpoint 1. Continuing.
Breakpoint 1, connect () at ../sysdeps/unix/syscall-template.S:82
82 in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0 connect () at ../sysdeps/unix/syscall-template.S:82
#1 0x00007ffff7b28974 in openlog_internal (ident=<value optimized out>, logstat=<value optimized out>, logfac=<value optimized out>) at ../misc/syslog.c:386
#2 0x00007ffff7b29187 in __vsyslog_chk (pri=<value optimized out>, flag=1, fmt=0x40198e "%s", ap=0x7fffffffdd40) at ../misc/syslog.c:274
#3 0x00007ffff7b293af in __syslog_chk (pri=<value optimized out>, flag=<value optimized out>, fmt=<value optimized out>) at ../misc/syslog.c:131
当然，我可以通过自己进行openlog()来完全跳过这个特定的问题，但我猜我会在一些其他函数中遇到相同类型的问题。
我真的不明白为什么openlog_internal不使用动态符号重定位来调用__connect()，如果使用简单的LD_PRELOAD机制是否可能挂钩此__connect()调用。
我看到它可以完成的其他方式：
- 从LD_PRELOAD中使用dlopen加载libc.so，使用dlsym()获取libc的__connect地址，然后对该函数进行修补（ASM wise）以使钩子正常工作。这似乎非常繁琐且容易出错。
- 使用修改过的自定义libc for PHP直接修复这些问题的源代码（打开/连接/映射函数...）
- 编写LKM，将文件访问重定向到所需位置。优点：无需ioctl(SENDFD)和chroot外部的守护进程。
我的谷歌搜索与“hook syscalls”相关，发现了很多关于LSM的参考资料，但它似乎只允许ACL回答“是”或“否”，而不允许重定向open()路径。
谢谢阅读。