The earlier discussions about whether to include xt_SYSRQ in mainline seem to have petered out with no clear consensus. As I recall, there were two suggestions as an alternative: use k(g)dboe and use a dedicated standalone module.
The former suggestion, kdboe, doesn't seem to fly because it's not in the kernel and also (unless I'm mistaken) provides little or no concession to security. It's great for development but in the case where xt_SYSRQ can be used in a production environment, it doesn't seem to work. Providing the environment for the debugger to work in is also likely to involve installing a lot on a production machine that wouldn't normally be there. (xt_SYSRQ is nice and light and would sit nicely alongside, for example, netconsole.)
The standalone module is troublesome. If I was starting from scratch with that I'd be putting in filters and whatnot that match those provides by xtables anyway. If everything apart from the actual function (sysrq) and password control is duplicated by xtables then you'd have to ask "why isn't this part of xtables?".
I know xt_SYSRQ is used by quite a few people and it is seen as generally useful, so what needs to be done to get this into the mainline kernel? Once it's there it stands a good chance of being backported to some of the production kernels (RHEL6, I'm looking at you) but without having some upstream commitment that seems a distant dream.
if xt_SYSRQ isn't acceptable, what is? (Bearing in mind that I believe that whatever it is needs to be acceptable to a production environment.)
jch -- 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
