Quoting Miloslav Semler (majkls@prepere.com):Yes, to understand why that doesn't work it helps to understand why pivot_root *does* work. Pivot_root takes the new_root, which must be a mount, and detaches it from it's mountpoint. So it's not that we try to intercept a chdir(root_dir/..), but rather we remove root_dir from it's parent dir so that root_dir/.. must always return root_dir. I'm sorry but I really don't see where hacking chroot to try and detect and prevent chroot escapes is going to be acceptable to anyone so long as pivot_root does the trick anyway. If you want portable, then write a little linux-only safe_chroot() library call which does unshare();pivot_root() on linux and just chroot on a system that does try to stop chroot escapes. Besides as others have alluded to, if you have root privs, you can always mknod /dev/hda1, mount that under /mnt, and then chroot or pivot_root to there. The containers work will, in fact, be intended to be a *safe* jail. That'll happen through pivot_root, capability masking, perhaps device namespaces, etc. But a secure container is still a ways off. -serge -
| Pierre Ossman | Re: [RFC][PATCH] cpuidle: avoid singing capacitors |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Greg KH | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| Rene Herman | 2.6.26, PAT and AMD family 6 |
git: | |
| Jesper Krogh | Re: NIU - Sun Neptune 10g - Transmit timed out reset (2.6.24) |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Arjan van de Ven | Re: [GIT]: Networking |
| Radu Rendec | htb parallelism on multi-core platforms |
