Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have some device (say /dev/sda1) mounted at /home/user1. I also have a full Linux system under /tmp/chroot, and the directory /tmp/chroot/home contains only one directory named user2.

If I chroot inside /tmp/chroot, mount /dev, /sys and /proc there and issue the mount command (or cat /proc/mounts), I can still see /dev/sda1 mounted at /home/user1 whereas the directory /home/user1 does not even exist anymore (in the chroot).

I also tried with jchroot instead of chroot (this is a program with an interface similar to chroot but creating a new mount namespace and a new PID namespace), but the results are the same.

Is this normal behaviour? It sounds weird that I can access information about mount points outside the chroot.
Is there a way to make them disappear from /proc/mounts?

share|improve this question

migrated from stackoverflow.com Nov 23 '11 at 7:42

This question came from our site for professional and enthusiast programmers.

Yes, you would need to use "unshare" instead (or as well as) chroot; chroot ONLY changes the root directory of the process. While it's difficult in practice to get to anything which is above it, there are many ways to break out. It's not a jail.

There are some tools which do this, such as "lxc" (Linux containers)

share|improve this answer
As far as I can tell, the unshare command will not do anything more than jchroot, it just uses the mount namespaces features, and I already checked (with jchroot) that this does not work any better. – Guillaume Brunerie Aug 23 '11 at 23:23
@Guillaume Brunerie: You should be able to umount the offending mountpoints within the new mount namespace, though (which will remove them from /proc/mounts for that namespace). – caf Aug 24 '11 at 3:18

This is the expected behavior within a chroot. The chroot really only changes what the process sees as the root directory of the filesystem '/' to a different directory than what was mounted as '/' at boot time. Said process still has the same global access to the kernel itself, just not to the '/' file system.

The kernel does not do any fixups or emulation to /proc or devices to make the chrooted process believe the chroot is 'real'. As a side effect of this, any process running as a superuser in a chroot can trivially break out of the chroot in many ways (eg, mount /dev and mount /dev/sdaX where the real root is, or even just mknod a new device entry and mount using that-- the kernel doesn't care). The chrooted process could even insmod a device driver and do whatever it likes...

If you are looking to 'trick' a process into thinking its running under a different system than it is currently running or to provide a layer of security, chroot is probably the wrong technology, I'd recommend looking into User Mode Linux or possibly Linux Containers

share|improve this answer
Would it work with lxc? I thought that Linux Containers was nothing more than chroot + mount namespace + PID namespace + a few others namespaces. – Guillaume Brunerie Aug 24 '11 at 11:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.