Linux – Mount points in a chroot

chrootlinuxmount

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?

Best Answer

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)

Related Solutions

Unable to mount raid on the NAS, trying to rescue the data, how should I proceed

This is an attempt to summarize from the chat troubleshooting session.

The setup turns out to be physical disk -> mdraid raid1 -> LVM. So there are several layers to work through. The old setup was (due to unfortunate prior recovery efforts) not available.

However, the NAS gui had been used to create another volume on a different disk, and thankfully the GUI created the new volume exactly the same way. So it was possible to discover the setup from the new disk:

mdadm -E new-disk provided the offset to the start of the data, under the mdraid layer (2048 sectors).
dmsetup table provided the start block of the logical volume (relative to the start of the physical volume) (1152 sectors)
There is a magic number (0x53ef) in the third sector of an ext4 volume. Using dd and xxd, we verified that the magic number is present at that offset on the disk we're trying to recover data from.

Armed with the start sector of the ext4 filesystem, you can use a read-only loop device to recover the data:

# losetup /dev/loop0 -o $((512*(1152+2048))) -r /dev/sda1
# mount -text4 -o ro /dev/loop0 /mnt

And then copy it off.

Mounting – Recursive Umount After Rbind Mount

This worked for me correctly -- https://unix.stackexchange.com/a/264488/4319:

mount --rbind /dev /mnt/test
mount --make-rslave /mnt/test
umount -R /mnt/test

It was important to have the two first commands as two separate commands: do not combine --rbind and --make-rslave in one invocation of mount.

Without --make-rslave, the behavior was unwanted (and not successful):

umount -l would affect the original old mountpoints, too,
and umount -R would be affected by the busy (open) files under the original old mountpoints. (Very unexpected...)

Best Answer

Related Solutions

Unable to mount raid on the NAS, trying to rescue the data, how should I proceed

Mounting – Recursive Umount After Rbind Mount

Related Question