H. Peter Anvin wrote:
> Then why not just let this be done in userspace (chdir, chroot, exec)?
Not all kernel threads change their root/cwd when init chroots. I've
found four possibilities for fixing this:
- find them all and current->fs = &init_task.fs; (plus update all the
reference counters). Risks: if one of them does an unexpected chdir or
chroot, the system may be in deep trouble. If we overlook one, we
still can't umount root.
- find them all, and put them in a little dentry-jail (a dentry that
points back to itself and has only no-ops in its inode). Risks: if
we overlook one, we still can't umount root. If one of them actually
does use the file system, and we just overlooked it, we've broken it.
- let them do whatever they want and then force them to the right place,
unless it's obviously dangerous.
- find them all, and call exit_fs. This works in principle, but it's
very easy to overlook any further cloning they do, which crashes
fork. Also, any unexpected attempt to access files, crashes the
thread. There may be other dependencies on current->fs != NULL that
I didn't find.
BTW, a non-solutions:
- make them all inherit current->fs from init (CLONE_FS). Doesn't work,
because they may be launched from modules or in response to some
user process' activity (e.g. rpciod, lockd).
"unexpected" here means something that was overlooked when adapting
the kernel thread, or that was introduced at a later time by somebody
who didn't know the new rules.
"finding them all" includes anything that comes from modules
maintained outside the mainstream kernel. And even with the things in
the mainstream kernel alone, I wouldn't feel comfortable at all
changing a few dozen people's code without even knowing whom to warn
about the change ...
kernel_thread should probably have had some FS-less default behaviour
right from the beginning, but now it's hard to put the genie back in
the bottle.
Also, if we can still build executables that don't keep the executable
file busy, one can build demons that don't keep / busy, if there's a
global chroot. This may be useful for some network-related demons.
- 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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:16 EST