If socket() is called to create a socket of that family, yes.
> int net_expect_family(int f) {
> int i;
> static int modules[] = {
> #ifdef CONFIG_IPX_MODULE
> AF_IPX,
> #endif
> #ifdef CONFIG_PACKET_MODULE
> AF_PACKET,
> #endif
> #ifdef CONFIG_ATALK
> AF_DDP,
> #endif
> [...] other protocols
Surely it is best not to make the kernel vary according to the modules that are
being compiled with it¹. If we do, then we should change the configuration
choices from {Yes,No,Module} to {Yes,Never,No,Module}.
¹ I'm currently beating my head against the wall trying to get the PC speaker
driver to obey this rule, and not require _any_ code in the kernel. The thought
of adding gratuitous such dependencies makes me shudder.
What if someone creates a third-party module, or compiles the a module
separately, after the kernel is distributed across all the machines in the
company? (I've done this at least three times in the last week, IIRC)
If you _must_ do this, then please limit it to net protocols, not all character
and block devices, and at least make it a list of exclusions, not a list of
inclusions, so that the default for a new protocol is to attempt to load
it.
> Something else while I remember, any user can use this as a pretty
> effective DoS attack via syslog; "for(;;) socket(21,0,0);"
This kind of thing has come up frequently, and was the reason that
net_ratelimit() was provided. You can manage this by repeatedly requesting
other modules, too.
Perhaps the solution to the potention DoS, and the to original 'problem', is to
limit modprobe's output. Let it keep a database of the last time it complained
about the absence of each module, or just disable the complaints completely.
Does modprobe accept wildcards in /etc/conf.modules?
alias net-pf-* off
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
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/