first attempt at making chroot nestable

first attempt at making chroot nestable

Post by Shaya Potte » Wed, 23 Oct 2002 20:50:20

This is a first attempt at a change that lets kernel's chroot's and wont
let you use an fd to break out of a chroot, it will only let you get as
far as the root as of when you got the fd (or possibly even less).

I've discussed the algorithm I've implemented below a couple times
already on the list, but I doubt my coding style is up to snuff, so
criticize away on that.  I also haven't had a chance to test it yet
(need to get into school to use the test machines), so all I know is
that it compiles w/o any warnings.

please comment away (as well as tell me if I did right my inline'ing the
patch, or if I should attach it, if it matters the mail client I
normally use is evolution)



diff -Naur linux-2.4.19/fs/open.c
--- linux-2.4.19/fs/open.c      2002-10-22 14:28:48.000000000 -0400

        set_fs_root(current->fs, nd.mnt, nd.dentry);

+       write_lock(&current->fs->lock);
        cp->mnt = mntget(nd.mnt);
        cp->root = dget(nd.dentry);
        cp->next = current->cp;
        current->cp = cp;
+       write_unlock(&current>fs->lock);

        error = 0;
diff -Naur linux-2.4.19/include/linux/sched.h
--- linux-2.4.19/include/linux/sched.h  2002-08-02 20:39:45.000000000 -0400

 /* journalling filesystem info */
        void *journal_info;
+       struct chroot_point *cp;

     blocked:           {{0}},                                          \
     alloc_lock:                SPIN_LOCK_UNLOCKED,                             \
     journal_info:      NULL,                                           \
+    cp:                        NULL,                                           \

diff -Naur linux-2.4.19/kernel/exit.c
--- linux-2.4.19/kernel/exit.c  2002-08-02 20:39:46.000000000 -0400


+static inline void __exit_chroot(struct task_struct *tsk)
+       struct chroot_point *cur, *next;
+       cur = tsk->cp;
+       task_lock(tsk);
+       tsk->cp = NULL;
+       task_unlock(tsk);
+       while (cur)
+       {
+               kfree(cur->mnt);
+               kfree(cur->root);
+               next = cur->next;
+               kfree(cur);
+               cur = next;
+       }
+void exit_chroot(struct task_struct *tsk)
+       __exit_chroot(tsk);
  * We can use these to temporarily drop into

+       __exit_chroot(tsk);
diff -Naur linux-2.4.19/kernel/fork.c
--- linux-2.4.19/kernel/fork.c  2002-08-02 20:39:46.000000000 -0400

        int retval;
        struct task_struct *p;
        struct completion vfork;
+       struct chroot_point *cp_p, *cp_c;

        if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))

        p->tgid = retval;

+       /* copy chroot_point list from parent to child */
+       cp_p = current->cp;
+       cp_c = NULL;
+       if (cp_p)
+               cp_c = (struct chroot_point *) kmalloc(sizeof(struct chroot_point), GFP_KERNEL);
+       p->cp = cp_c;
+       while (cp_p)
+       {
+               cp_c->root = dget(cp_p->root);
+               cp_c->mnt = mntget(cp_p->mnt);
+               cp_c->next = NULL;
+               if (cp_p->next) {
+                       cp_c->next = (struct chroot_point *) kmalloc(sizeof(struct chroot_point), GFP_KERNEL);
+                       cp_c = cp_c->next;
+               }
+               cp_p = cp_p->next;
+       }
        /* Need tasklist lock for parent etc handling! */

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at
Please read the FAQ at


1. first step in making chroot nestable?

in looking through the code, it seems the follow_dotdot() function in
fs/namei.c is the ultimate part of how the kernel keeps programs jailed
into a chroot.

basically (very basic) what it appears to do is

if (place we chrooted == current place)
        we're at the root

If we would have a linked list of chroot points, and whenever we hit one
of those points in a walk, we treat it as a root, wouldn't this chain
any fd's one brought into a chroot to the original root of that fd.

yes, there are other things that would have to be taken care of to make
a chroot jail more secure, but this should be an easy thing, correct? or
am I missing more.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at
Please read the FAQ at

2. ppp problem

3. Chroot setup gets 530 error on ftp attempts

4. High Performance Disk Subsystem

5. 8mm Jukeboxes, who makes them, where can I get one, which one?

6. What/Where is

7. making popen() work in a chroot environment in irix (solution)

8. Buying To Benefit FreeBSD

9. can chroot be made safe for non-root?

10. any way of making login have less or more bad password attempts?

11. M$ makes an ATTEMPT at patching Outlook

12. chroot+Apache: possible to place logfiles outside chroot cell?

13. BIND config tool + How do I select between chroot and no chroot?