Jozsef Kadlecsik wrote:
On Sun, 14 Dec 2008, Jan Engelhardt wrote:
In a >normal< system one usually does not use raw sockets. So if a root
process do use raw socket, at least netfilter sends a notification and
there's a chance that someone take notice it by checking the kernel logs.
[...]
But should we remove them due to nuisances on >test< systems?
Rather make it a kernel compile option but do not remove.
This warning is in the conntrack calling code. Iff you play with
raw sockets and do something wrong, the generic network code
should barf IMHO, not nf_conntrack, and not [nf_conntrack_ipv4 only].
It is not about doing something wrong at using raw sockets - it's about
using raw sockets.
I'm not quite convinced the generic network code should warn about raw
sockets. I believe it belongs to the security-related subsystems -
netfilter and (or) the security frameworks. [But as netfilter is much more
widely used, the 'or' is just theoretical.)
I agree that it doesn't belong to the generic networking code.
But the way its handled in netfilter is far from perfect as well.
Currently multiple modules will spam the ringbuffer repeatedly,
but offer no possibility to change anything in the behaviour of
how these packets are treated. Unfortunately we can't handle this
in the ruleset (which is exactly the reason why we're spamming
the ringbuffer), so how about we add a module option controlling
how to treat those packets and remove the printk?
In the case of conntrack I would even argue that the message
makes no sense at all since tracking doesn't matter as long as
the state isn't used. And for that the table code can warn or
offer controls.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
