From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 1/2] netfilter: xtables: inclusion of xt_SYSRQ Date: Wed, 21 Apr 2010 15:17:00 +0200 Message-ID: <4BCEFACC.7020804@trash.net> References: <1271845618-28569-1-git-send-email-jengelh@medozas.de> <1271845618-28569-2-git-send-email-jengelh@medozas.de> <4BCEF6B4.8090105@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Netfilter Developer Mailing List , Linux Netdev List , John Haxby To: Jan Engelhardt Return-path: Received: from stinky.trash.net ([213.144.137.162]:40786 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754417Ab0DUNRB (ORCPT ); Wed, 21 Apr 2010 09:17:01 -0400 In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: Jan Engelhardt wrote: > On Wednesday 2010-04-21 14:59, Patrick McHardy wrote: > >> Jan Engelhardt wrote: >>> The SYSRQ target will allow to remotely invoke sysrq on the local >>> machine. Authentication is by means of a pre-shared key that can >>> either be transmitted plaintext or digest-secured. >> I really think this is pushing what netfilter is meant for a bit >> far. Its basically abusing the firewall ruleset to offer a network >> service. >> >> I can see that its useful to have this in the kernel instead of >> userspace, but why isn't this implemented as a stand-alone module? >> That seems like a better design to me and also makes it more useful >> by not depending on netfilter. > > That sort of diverts from the earlier what-seemed-to-be-consensus. > > Oh well, I would not mind holding the single commit up as long as the > rest isn't blocked too :-) Then lets skip this one for now.