为什么Linux允许'init = / bin / bash'？

我最近发现，如果在启动前编辑GRUB并添加rw init=/bin/bash，则最终得到的是root shell。

在我想了解一切的情况下，我想知道为什么会这样。我的意思是这是个错误吗？这是功能吗？是否可以帮助管理员修复问题，因为只有在对计算机具有物理访问权限的情况下它才能起作用？

它是由GRUB还是实际的内核提供的？

这是一项功能，用于系统维护：它允许sysadmin从混乱的初始化文件中恢复系统或更改忘记的密码。

红帽邮件列表中的这篇文章解释了一些事情：

在类似Unix的系统中，init是第一个要运行的进程，并且是所有进程的最终祖先。它负责运行所有初始化脚本。

您要告诉Linux内核将/ bin / bash作为init而不是系统init运行。[...]

因此，您没有利用任何东西，只是在使用标准的内核功能。

此外，如注释中所述，该rw标志与分开init=，它只是告诉系统以读写方式挂载根文件系统（因此，例如，您可以编辑错误配置的文件或更改密码）。

您的系统具有运行和调试的机制（如init参数），并且它可能具有安全机制，以阻止不需要的用户利用它们。这些是功能，而不是错误。

引导加载程序负责启动操作系统。当时，操作系统安全性显然不适用。您可以只加载一个不同的内核，initrd，root fs或设置其他选项（例如init路径）。如果要阻止用户这样做，则必须在引导加载程序中完成。

您的系统（可能是PC，所以是BIOS）将加载引导加载程序，因此，显然，引导加载程序的安全性不适用于它。如果要阻止用户从USB或类似设备引导BIOS，则需要在该级别上执行此操作。

您的系统可能在某处的桌子上。如果要阻止用户打开计算机并为自己的硬盘切换硬盘或卸下驱动器以将其安装到计算机中，则需要在物理级别上进行操作。而且这不会阻止他们拿起整个桌子并开着他们的逍遥客...

这就是安全性的方式。大象一直走下去。

计算机启动时，会运行一个名为“ init”的程序，通常在/bin/init或处找到/sbin/init。该程序负责所有系统的启动和创建可用的环境。

指定init=/bin/bash告诉内核改为运行/bin/bash（这是一个外壳程序）。指定可以rw告诉内核以读写模式而不是只读模式引导硬盘。传统上，内核从磁盘以只读模式开始，随后的一个过程随后在切换到读写之前检查磁盘的完整性。

从kernel.org拼凑而成：

KNL     Is a kernel start-up parameter.

init=   [KNL]
        Format: <full_path>
        Run specified binary instead of /sbin/init as init
        process.

rw      [KNL] Mount root device read-write on boot

这是内核的功能：它允许其“调用程序”（即引导加载程序）具有极大的灵活性。Grub为您提供了在引导时利用这种灵活性的方法，但同时也为您提供了限制这种篡改的方法。在未经授权的用户可以控制启动过程但被拒绝访问硬盘驱动器本身的情况下，这特别有意义。

init=可以接受任何可执行文件

init=可以使用任何可执行文件，包括shell脚本。

例如，在这里我演示了如何创建一个任意的最小C编译init：如何创建一个只运行一个程序而没有其他程序的自定义Linux发行版？

那么，为什么它不接受/bin/bash所有只是常规可执行文件的东西，并且实际上会有用呢？:-)

接下来，您还应该尝试了解常规代码（init例如systemd或Busybox'）的权衡取舍

基本上，使用raw /bin/bash，您：

• 失去使用密码控制登录的能力。但这有时是合乎需要的，例如在进行系统仿真时：如何在不通过Buildroot BusyBox init输入根用户名或密码的情况下自动登录？
• 失去工作控制权，例如Ctrl + C将不起作用
• 如果执行Ctrl + C，则退出外壳，并且内核恐慌自init存在以来

作业控制可以在Busybox的”初始化恢复和其他类似inits具有领先-于inittab：

tty3::respawn:-/bin/sh

inittab如果您按Ctrl + D，则使用登录名并保留生成外壳程序的更普通的条目是：

::respawn:/sbin/getty -L ttyS0 0 vt100

哪个使用getty可执行文件，但是TODO：如果没有Busybox，我无法自行生成这些文件init：getty从命令行启动？

您可以使用此设置进行操作，并得出以上结论。