Whither xt_SYSRQ?

[John Haxby <john.haxby@oracle.com>]

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