[PATCH] root-hopping for pre-2.3.41-3

almesber en lrc.di.epfl.ch almesber en lrc.di.epfl.ch
Mar Ene 25 22:54:22 CST 2000


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 en 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 en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



Más información sobre la lista de distribución Ayuda