Let me put it this way: You *CANNOT* enforce chroot() the way you
want to without a completely unacceptable performance penalty. Let's
start with the simplest example of:
fd = open("/", O_DIRECTORY);
chroot("/foo");
fchdir(fd);
chroot(".");
If you had ever actually looked at the Linux VFS, it is completely
*impossible* to tell whether "fd" at the time of the chroot is inside
or outside of "/foo" without tracking an enormous amount of extra
state. Even then, any such determination may not be valid since an
FD may be opened to an inode which is hardlinked at multiple
locations in the directory tree. It could also be bind-mounted at
multiple locations, or it may not even be mounted at all in this
namespace (CDROM that was lazy-unmounted). That FD may be later
passed over an open UNIX-domain socket from another process.
Moreover, arbitrarily closing FDs would break a huge number of
programs. Furthermore, since you can't fix the "trivial" case of
'fchdir()', then there's no point in even *attempting* to fix the
"cwd is outside of chroot" problem, although that is basically
equivalent in difficulty to fixing the "dir-fd is outside of chroot"
problem.
As for the nested-chroot() bit, the root user inside of a chroot is
always allowed to chroot(). This is necessary for test-suites for
various distro installers, chroot once to enter the installer
playpen, installer chroots again to configure the test-installed-
system. Once you allow a second chroot, you're back at the "can't
reliably and efficiently track directory sub-tree members" problem.
So if you think it can and should be fixed, then PROVIDE THE CODE.
Cheers,
Kyle Moffett
-
