[klibc] klibc insmod for recent kernels

[Rusty Russell]

In message <3E18C296.80004@zytor.com> you write:
> Rusty Russell wrote:
> >>
> >>Sure, but why spawn /bin/sh to do it?  It seems doing it internally 
> > would be both cleaner and faster.
> > 
> > Loading modules is hardly speed sensitive.  "install foo
> > /sbin/modprobe pre-foo && /sbin/modprobe foo" for example.  You may
> > want to do arbitrary things, and forcing you to write a shell script
> > isn't a really gread idea.
> > 
> 
> It isn't, but it creates lots of unwanted dependencies and quite 
> possible security holes (bash is big and complex and uses environment 
> variables in unsundry ways.)

Yes.  But you're root, for a start, and second, I have a patch which
closes any request_module hole (by not forking the thread off whatever
thread calls request_module and then trying to clean the enviroment,
but by using a known-clean kevent thread).

> Perl, for example, only invokes /bin/sh if the command presented to it 
> includes shell special operators (like your && above.)  Another variant 
> -- which is probably better -- is to simply make the user make use of 
> "sh -c" if that's what they really want to do.

Well, those options both suck.  The first is a bogus optimization and
extra complexity for no reason (in this case), and the second is
almost as silly.

> (By the way, you realize the example above creates an infinite loop,

Yes, I skipped the "/sbin/modprobe --ignore-install foo" for brevity.

> and that would be much better handled by giving modprobe a way to
> introduce dependencies directly, right?)

"Better"?  modules.conf has seven ways of doing this: above, below,
pre-install, pre-remove, post-install, post-remove, install and
remove.

And that makes it *so* much better 8)
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.