Messages in this thread | | | Subject | Re: [PATCH 12/18] shared mount handling: bind and rbind | From | Shaya Potter <> | Date | Wed, 16 Nov 2005 15:21:43 -0500 |
| |
On Wed, 2005-11-16 at 23:05 +0300, Al Boldi wrote: > Shaya Potter wrote: > > I created a patch years ago that creates a chain of "chroot" points, and > > any past chroot point would be considered a place that follow_dotdot > > would consider a root. There didn't seem much interest in the patch > > though. > > Could you resubmit this patch for possible inclusion in 2.6.16, and make it a > runtime option such that the default behaviour remains unchanged?
resubmit? It was a long long time ago (middle of 2.4 era) I'd have to find it, who knows if its still around.
Conceptually it was pretty simple, basically instead of just overwriting the fs struct root/rootmnt you create a linked list of them (appending on every chroot). I think I might have had a seperate struct to maintain that linked list (it wasn't the best code in the world).
follow_dotdot is then modified so that the code
if (nd->dentry == current->fs->root && nd->mnt == current->fs->rootmnt) { read_unlock(¤t->fs->lock); break; }
instead of being just a single test, loops over every element in the linked list. Hence, if you are ever at a "chroot" point, you get a root, so solves the simple problem of breaking out of a chroot by calling chroot() again. In the normal case (no chroot), there should be no real performance hit, as it would hit the loop once.
However, as others have said, if you can make a device node, then you can break out of it in other ways.
Now, there are other things one has to take care of.
1) Obvious: cleaning up the list on process termination. 2) Obvious: propagating list to child processes.
and probably some less obvious things that I don't remember or didn't even consider at the time.
- 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/
| |