Chroot bug take 3

From: David Newall
Date: Sat Sep 29 2007 - 11:22:16 EST


I hope I haven't crossed the line between determined and annoying. I thought we were done, but now I find meat still on this bone.

Posit a normal process having some filesystem root, and a current working directory (pwd) lying within that root subtree. When chroot is performed, pwd is left unchanged. This means it can (and often will) lie outside of the new root.

How much of the filesystem lying outside of root should a process be allowed to access? Currently it is the complete filesystem.

It is perfectly reasonable for a process to execute chroot multiple times, each time pruning off access to further parts of the filesystem. What is *not reasonable* is chroot unavoidably returning access which previously had been dropped. Similarly, performing fchdir on a directory opened prior to chroot should not grant access to more of the filesystem than was accessible when the directory was opened.

Although chroot can result in pwd lying outside of the new root, is must still lie within some root. A new quantity, openfdroot, will be recorded by chroot, to be used as the limit when walking dotdot outside of the current root.

The initial value for openfdroot is the complete filesystem. After completing each chroot, as well as chdir, fchdir and close, openfdroot will be set to root iff all open directories and pwd lie within that root; otherwise it remains unchanged.

In an ideal world a separate openfdroot would be recorded for each open directory, and another for pwd, however this is extreme. A single value permits chroot to perform its fundamental promise, namely to prune the root

The following might replace the last two paragraphs in chroot(2)'s description:

This call does not change the current working directory. After the
call, '.' can be outside of path, thus files, accessible to the
process before the call, remain accessible (via relative pathnames)
afterwards. This access is intrinsicly dropped by changing
directory to within the new root.

This call does not close open file descriptors, and such descriptors
may allow access to files outside the chroot tree. A successful
open(2) on a directory outside of path yields a descriptor that can
subsequently be passed to fchdir(2) to escape the new root. This
will only provide access to as much of the filesystem as was
accessable when the directory was opened. Closing all such files
(and changing directory to within path) drops this access.

Would there be any point in working up a patch?
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