Thank you!
[...]
>Basically, unless you want chroot:ed processes to lose the ability
>to use auto-loaded kernel features, you will have to copy all
>modules to every point where chroot:ed processes will run. This
>is both a significant change in semantics and a maintenance headache.
This is no different than with shared libraries, and has the
similar minor advantage of allowing customization of which facilities
can be accessed by the chroot'ed user.
To some extent, I regard this as a feature, because I envision
using chroot to create somewhat insular environments, like say, an
xterm process running chroot'ed to a test linux distribution. If I'm
a really careful sysadmin, I may even want to restrict the modules
that the anonymous FTP process can load, if any. However, I can see
arguments both ways.
>Thinking further about this, I think the following changes to
>Adam's version should fix this problem: in exec_modprobe(),
>1. nullify current->fs
>2. set current->fs to reference that of init/kswapd/et al
You mean "init", because you want to follow init's
chroot calls.
I worry about process synchronization issues here.
>3. remove the stat() call
>4. execve() modprobe.
>This should (unless I'm missing something) eliminate the chroot problem.
>I'll try to work out a concrete patch this weekend.
Go for it, but I hope that my kmod changes that I have submitted
to Linus will go into the next kernel, because they resolve the
big kmod problems. In principle, I am neutral about your proposed changes
once they have been tested to make sure there are no synchronization
problems.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu