Bug 171885

Summary:	Support for ipt_sysrq
Product:	Red Hat Enterprise Linux 4	Reporter:	Kjetil T. Homme <kjetilho>
Component:	kernel	Assignee:	Red Hat Kernel Manager <kernel-mgr>
Status:	CLOSED WONTFIX	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	jbaron
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-20 16:19:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kjetil T. Homme 2005-10-27 14:09:56 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
http://terminus.sk/~marek/prog/ipt_sysrq.shtml

has a kernel module and user space tool which would be very useful for many enterprise customers with large campuses.  we have several hundred of computers spread over a radius of a kilometre, and it would be nice to be able to reboot the remote computer in a semi-controlled manner.  this would be useful when you screw up the DHCP setup for a PXE booted computer.  it might even be useful in a rackmount setting (I've had servers with non-responsive serial console, but living network.)


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
 

Additional info:

Comment 1 Thomas Graf 2005-11-20 21:05:55 UTC

Even though various mechanisms have been implemented to reduce the risk of
abuse and unintentional use of this iptables target it is very dangereous.
A single malformed packet could be triggering a reboot on a remote machine
unintentionally. Therefore ipt_sysrq will never be included upstream which
means it will not be part of RHEL.

There is a certain value in this method but its use is very limited since the
majority of cases where sysrq interaction would be required do no longer allow
for network access, not even a single packet. It definitely doesn't replace
reliable remote power management solutions.

Comment 2 Kjetil T. Homme 2005-11-20 21:45:23 UTC

your experience deviates from mine.  we have weekly occurences of workstations
which respond to ping, but does not allow SSH.  the reasons for this can be
many, it can be a fork bomb mistakenly set off by a student or NFS hangs
overwhelming the kernel.  of course ideally these things wouldn't cause the
workstation to be unoperational, but as long as the kernel is non-perfect, this
would be a nice safety valve to helps run our terminal rooms more smoothly.

I don't see the issue of security.  this should not be enabled by default, of
course, and the people who want to use this feature will tend to have the
network equipment and prowess needed to make it secure.  if locked down to a
specific IP address, the chance of a malformed packet triggering it is very low.
 if the password is a hash specific to each workstation, the potential for large
scale harm via replay is minimised.

installing reliable remote power management is unfortunately not an option for
our 400+ workstations.

Comment 3 Jiri Pallich 2012-06-20 16:19:45 UTC

Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.