Also, last I heard chroot is not secure for sandboxing, so why bother with it at all? I'd use cgroups or even lxc containers (those are pretty well supported in the latest ubuntu).
It is probably better than nothing (hard to get root if everything in the chroot is running as a user, no suid files, few devices). Probably need a kernel exploit then to get out. A container is better though.
Yeah, so what's the point? If you have a separate user, you can't access other users' files anyway, unless you have root. You can access the system files, but there should be nothing of much interest in there anyway.
You should have only the minimum necessary commands and libraries in your chroot jail which minimizes the attack surface. For instance, I use chroot with rssh to only allow sFTP/scp/rsync and not allowing chroot users to get to a shell prompt.
In my chroot /usr/bin, there are only two files (rssh, scp). In my chroot /lib there are only 16 files.
I guess to prevent an application (e.g a web server running as a non root user) from easily reaching outside and running arbitrary shell commands or reading files.
For example if you have something horrible like a PHP script that does: echo system($_POST['whatever']) you at least should try and prevent it from doing "ls" and "cat" to start exploring the filesystem.
You're correct. chroot works on a per-process basis by adding a relative fs root into the process (or process table? dunno) memory. If you're root, you can change it back to /.
Also, last I heard chroot is not secure for sandboxing, so why bother with it at all? I'd use cgroups or even lxc containers (those are pretty well supported in the latest ubuntu).