为什么在某些系统上默认情况下未启用 Magic SysRq？有风险吗？

Question

在对 Oracle Linux 6.3 服务器 (RHEL Derivative) 进行故障排除时，我第一次尝试使用一些 Magic SysRq Key 命令。没有这样的运气，所以我不得不硬重启。当它恢复时，我检查了是否启用了 SysRq...

> sysctl kernel.sysrq
kernel.sysrq = 0

但是在我们的 Oracle Linux 7.2 (RHEL Derivative) 系统上...

> sysctl kernel.sysrq
kernel.sysrq = 16

查看 sysrq的内核文档：

0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function
description):
     2 =   0x2 - enable control of console logging level
     4 =   0x4 - enable control of keyboard (SAK, unraw)
     8 =   0x8 - enable debugging dumps of processes etc.
    16 =  0x10 - enable sync command
    32 =  0x20 - enable remount read-only
    64 =  0x40 - enable signalling of processes (term, kill, oom-kill)
   128 =  0x80 - allow reboot/poweroff
   256 = 0x100 - allow nicing of all RT tasks

根据Fedora 的 Sysrq QA：

股票 Fedora 和 RHEL 内核确实在编译时启用了此功能，但发行版在启动时禁用它，默认情况下，使用 sysctl.conf。

在我们所有的系统上默认启用此功能似乎是个好主意。万一系统锁定，您至少可以半优雅地关闭它。

我的问题...

1. 如果这是一个明显的好主意，为什么该功能在 6.X 中被禁用，而在 7.X 中仅限于文件系统同步？
2. 在我们所有的系统上设置kernel.sysrq为有任何风险1吗？

Answer 1

您可能不希望随机某个人走到键盘前重置机器，或者更糟糕的是，在不登录的情况下开始将寄存器、系统日志或所有任务打印到控制台。这是一个潜在的安全问题。

例如，我有选择地在连接到串行控制台集中器的数据中心硬件上启用它。我在我们的最终用户工作站上禁用它。