I did see it, which is why I didn't post my message on Tuesday as
I had intended, but went back and thought seriously about the
different ways of realizing the functionality of kmod.
I agree that Adam's version is simpler, if by simpler one means
(a) shorter, or (b) uses less kernel resources. This is good.
But executing modprobe in the context of a user-level process (which
isn't even aware if this happening) makes it IMHO _more_ complex.
I believe Adam's second version to be safe (protecting both user
and kernel from rogue modprobes), but the fact that it executes
with the same file system root as the unsuspecting user is _serious_.
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.
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
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.
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu