Messages in this thread | | | From | Werner Almesberger <> | Subject | Re: [PATCH] root-hopping for pre-2.3.41-3 | Date | Fri, 28 Jan 2000 03:44:57 +0100 (MET) |
| |
Horst von Brand wrote: > As a (mostly) bystander, I find the idea of kernel internal threads > rooted in the filesystem somewhat strange, to be honest. That's why > I'd go for getting rid of that "feature".
Some kernel threads may have legitimate reasons for accessing the file system, e.g. nfsd and khttpd, so you can't just disallow it completely. Worse yet - some kernel threads may touch file system code in a pretty non-obvious way, e.g. when lockd spawns a sub-thread, current->fs gets de-referenced, so if you did an exit_fs first, oops ... (I stopped looking for other cases after this sobering discovery, so maybe this is the only one, which could be easily fixed, but I wouldn't bet on it.)
H. Peter Anvin wrote: > Well, the reason for it is for orthogonality in the kernel; avoiding > special cases. I like the fake root/cwd idea, because it lets us create > the special case without breaking orthogonality.
Yes, I think it would be good to research this for 2.5. It may be a pain to get right, though, e.g. I'm not sure if we can build a "dentry jail" with d_inode == NULL. If we can't, we need an "inode jail" too, and then maybe a "super block jail" and a "blockdev jail". I hope not, but it may get pretty complex in the end.
Anyway, I'll document pivot_root(2) (which is in pre-2.3.41-4 - thanks, Linus !) such that the global chroot happens, but that only a chroot of the current process can be expeced (not strictly necessary, but gives better semantics), and extend pivot_root(8) accordingly.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |