from vserver patch
diff -rc2P linux-2.4.19/fs/namei.c linux-2.4.19ctx-14/fs/namei.c
*** linux-2.4.19/fs/namei.c Tue Aug 6 15:02:24 2002
--- linux-2.4.19ctx-14/fs/namei.c Sun Oct 13 23:58:55 2002
***************
*** 153,156 ****
--- 153,165 ----
umode_t mode = inode->i_mode;
+ /*
+ A dir with permission bit all 0s is a dead zone for
+ process running in a vserver. By doing
+ chmod 000 /vservers
+ you fix the "escape from chroot" bug.
+ */
+ if ((mode & 0777) == 0
+ && S_ISDIR(mode)
+ && current->s_context != 0) return -EACCES;
if (mask & MAY_WRITE) {
/*
I don't think that will work, especially as it seems vserver's dont
nest.
I described an algo (on this list a day or 2 ago) that should work for
fixing the fd problem (everything else seems to be root's power related,
not chroot related)
we add a new field to the task_struct, which is some linked list of
chroot points, normally null for non chrooted processes.
when we call chroot, we dont just change the fs_struct, we pre-append
the same data as a linked list node to the beg of the list (i.e. the
element in the task struct)
in follow_dotdot() instead of checking against the fs_struct, we
basically say
if (!current->chroot_points)
; //we know we are not chrooted
else
for each element in chroot_list
if current dir = chroot dir
chroot = true;
break
if ( chroot )
do whatever kernel does now
else
do whatever kernel does now.
on fork, all you have to do is copy the list efficiently b/w parent and
child.
the reason this works, is that any fd you get has to be inside a chroot
point (or within the original root), therefore if you try to chroot
under a chroot while holding fd's, there will be a .. of one of those
fd's that will be a chroot point, that you can kill the path_walk at.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/