Unfortunately, chroot() is breakable on most implementations. Of course, you have to get root to do so, but, if you can get root you can do anything -- the key is preventing the root exploit.
Of course, you already know that. I'm not telling you anything you don't already know.
As to the Linux One Big Partition, well, you misunderstand, as my Linux system has multiple Big Partitions.... and, yes, I know full well from my Apollo Domain/OS days about the problems with hardlinks -- although, Domain/OS in later versions allowed hardlinks to span filesystems by making a virtual symlink, that could be used inside a chroot() jail -- but then again, Domain/OS chroot was very broken in other ways.
But, if you really want to do chroot, you really need a separate postmaster running inside the jail as well, as an outside postmaster could be exploited with carefully crafted queries (as PostgreSQL is also a C program). Thus, you need zero communications outside the chroot jail to make a chrooted OpenACS really work in a manner that is secure.
A jailed postmaster solves the /tmp issue. It also solves the TCP/IP issue.
<blockquote> 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.
</blockquote>
Then set it up so that the aolserver run user can't execute those programs. It's not hard. And, on a typical webserver, you shouldn't have that many suid programs. If you do, you have other problems.
And, again, what about postmaster/postgres being exploitable through a connection that originates on a web page? If they break you webserver, then can connect to your db server, they can break it too. And I happen to know of one security hole in PostgreSQL that has no fix as yet, involving a postgres superuser with no password. There will be others found -- I am currently researching to see if the format string bugs that have crippled rpc.statd, wu-ftpd, and now LPRng can wreak havoc on PostgreSQL, too.
So, if you're going to be paranoid about AOLserver, best be paranoid about PostgreSQL, too.
But, in its current state, chroot()ing OpenACS is more trouble than its worth -- at least until the perl portion gets rewritten to run in tcl inside the server. Then there's the fun with PostgreSQL in chroot -- which I don't think many people have done (not because it's hard, but because it's harder than running PostgreSQL securely outside chroot()).
I have been hacked once -- and it was BIND that done me in that time, not AOLserver.
But, again, if you want chroot(), and want it bad enough, by all means go for it. I'll even help out as much as I can give time to -- but, at this point, I don't think it is worthwhile to make chrootable RPM's for OpenACS unless and until chrootable RPM's exist for both AOLserver AND PostgreSQL.
