Yes, this can be done by overwriting libc calls or patching httpd process at runtime to overwrite open() at libc address map, and get open() calls trapped just for apache. BUT, let's figure a scenario: GD has a buffer overflow bug that when it tries to get the size of a existing malformed image (that can be uploaded by any user at web app), it segfaults. It's a exploitable bug, and a attacker sucessfully exploit it, binding a shell. Shellcodes don't make use of libc calls. Instead, they use direct asm calls to trigger system calls that they need to use (execve(), dup() for example of a connect-back shellcode). Your method will not trigger that exploitation, but a kernel-level wrapper will see that "/bin/sh" got executed by httpd, what is... unacceptable. Yes, I can patch the whole libc and expect when the attacker issue any "ls -la" that WILL be triggered by your patched libc wrapper. But I dont like userland patches like that (in fact, I prefer to avoid libc hackings like that). Imagine a libc wrapper that inside a read(), it makes a syslog() or anything to log... a simple strace will catch it up.
Returning to the topic context... the kernel sees everything. Libc just accept that and live with, as a wife =) I prefer to be the husband one... -- # (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/