Then again, you can create a hardlink inside the chroot jail to the /tmp dir easily enough.
Not if
/tmp is on a different filesystem from your chroot
jail, nor if the file gets deleted and recreated. Both conditions obtain on BSD systems where
/tmp is frequently a memory filesystem. I guess there are Linux types who favor the One Big Filesystem school of thought.
I totally disagree with the statement that chroot is more trouble than it's worth. Or at least, I think that if it's true, it should be made less trouble!
A non-chrooted AOLserver, on a typical PC, has access to a zillion setuid programs which will often have well-known security holes, as well as to other fun things like /tmp races. AOLserver is a C program, and I don't trust a C program not to have buffer overflows. Even if the AOLserver authors were perfect, their perfection wouldn't protect them from overflows in libc.
I agree that this is a minor threat for most people. AOLserver isn't widely used enough to make it worth writing a cookie-cutter exploit for it, and any holes found in it won't have the popularity of a hole that can be exploited in 100,000 RedHat boxes. But some breakin attempts aren't opportunistic attempts to find a place from which to do distributed DOS or to run an IRC daemon. Sometimes somebody wants your machine, and is willing to make the effort. And then you want to be protected.
In these cases it would be nice if it weren't gratuitously difficult to do so. Independent of security considerations I think it would be nice to remove the dependence on external scripts. The spirit of AOLserver seems to be very self-contained, to the point of incorporating log rotation internally, and sending mail by connecting to an SMTP server, rather than execing an external MTA, &c.
