如何修复丢失/重命名的 libc.so.6？

您应该从 live USB（或 CD/DVD）启动并重新命名libc.so.6。

LD_PRELOAD不适用于 setuid 可执行文件。但是，如果您愿意，您可以/bin/busybox在重新启动之前使用做最后一分钟的备份（不需要以 root 身份运行命令）。可以在没有实时 USB/CD/DVD 的情况下解决此问题，但您仍然需要重新启动，我建议使用一个。

LD_PRELOAD不适用于 setuid 命令。

目前，您正试图sudo通过设置来使用重命名的共享库LD_PRELOAD。这行不通。您无法使用 更改共享库sudo链接到的内容LD_PRELOAD，并且它不适用于任何替代方案sudo。如果你能做到这一点，那么这将是一个极其严重的安全漏洞。

允许您提升权限的方式sudo和pkexec（和）工作是这些可执行文件的 setuid 位设置^{为 0}，这导致它们以拥有它们的用户身份运行，对于这些可执行文件来说，该用户是 root 用户，而不是实际上运行它们。当他们运行时，他们会非常仔细地验证您要求他们做什么。这样，如果他们的开发人员足够小心，他们将只允许用户执行他们被授权执行的操作。su

LD_PRELOAD对其所有者以外的用户运行的 setuid 可执行文件无效。这对于安全来说绝对是至关重要的。否则，任何人都可以创建自己的库并强制某个程序喜欢sudo使用它，然后任何人都可以获得 root 权限。您可以使用它LD_PRELOAD来运行非 setuid 程序，而 root 可以使用它来运行几乎任何东西。但作为非 root 用户，您不能使用它来运行setuid rootsudo的pkexecsu

如果您已经运行了 root shell，则无需重新启动。但是，即使您启用了 root 帐户——也就是说，即使您为它设置了一个密码，您可以使用类似的命令以 root 身份登录——您su仍然无法在不重新启动的情况下解决问题. 例如su在 Ubuntu 中也需要libc.so.6并且也是 setuid root 所以LD_PRELOAD也不能使用它。¹（另见Peter Cordes的评论。）

这里的问题是，以 root身份执行操作的可用机制要求您以自己的身份运行 root 拥有的 setuid 可执行文件，但LD_PRELOAD在这种情况下无效。如果不是因为需要以 root 身份执行操作——或者如果你已经打开了 root shell——那么你可以很容易地重命名它而无需重新启动，也无需使用LD_PRELOAD. 这是因为 Ubuntu 系统有/bin/busybox，它是静态链接的。它允许您运行许多常见的 *nix 工具，包括mvandcp命令。您可以运行，也可以运行只是为了获得一个外壳，然后您可以在其中运行命令。跑/bin/busybox mv source destination/bin/busybox sh/bin/busybox没有参数来获取支持的命令列表。它甚至有一个版本dpkg！

您可以备份文件（如果需要）并重新启动到实时环境。

我提到busybox主要是因为，虽然您将无法使用它来获得 root 权限和恢复libc.so.6，但您可以在重新启动到实时环境之前使用它来备份您担心丢失的任何文件。我非常怀疑您会丢失任何东西，但是由于您担心，您可能希望busybox将任何重要文件（例​​如自上次备份以来创建或修改的文档）复制到另一个位置。

以通常的方式重新启动可能不会走得太远，因为正常关闭实际上涉及运行依赖于libc.so.6. 您可能希望使用Alt++SysRq安全REISUB地重新启动。这不是一种理想的关闭方式，但它可能比尝试重新启动几乎无效然后硬重置要好。另一种选择是尝试重新启动，然后尝试使用 REISUB 方法完成剩下的工作。（如果您想关闭机器而不是重新启动机器，请使用 REISU O而不是 REISU B。）

当您从实时环境启动时，重命名文件将很容易。你不需要chroot或做任何花哨的事情。只需挂载您的根文件系统（通常可以在文件浏览器中单击一下，但mount如果您愿意，也可以使用该命令）。然后，在终端中，使用mvorcp命令恢复libc.so.6. 您将需要sudo，但这在现场环境中可以正常工作。

我知道你提到你没有急救盘。在无法运行大多数程序的系统上创建可引导的 live USB 是很困难的，也许是不可能的。（您可以使用它busybox来复制和移动文件，它甚至还有一个dd命令，但我不建议您尝试使用它。通常您需要能够以ddroot 身份运行才能创建实时媒体。）也许有人会建议一个方法。如果你有另一台机器可以放入硬盘，希望你可以用那台机器创建它。如果没有，最好的办法可能是请熟人做一个。

有一种方法不需要 Live CD/DVD/USB，但您仍然必须重新启动。

但是，除了从外部媒体启动之外，还有另一种方法。²您仍然需要重新启动，但您不需要实时系统。我不特别推荐这个，因为它很麻烦；使用现场环境更容易。不过，如果你真的想的话，你可以在没有人的情况下做到这一点。

正如Zanna之前在评论中指出的那样，救援模式不起作用，因为大多数程序都需要libc.6.so（例如，/bin/bash提供 shell 的 ，需要它）。但是您可以通过将引导选项作为引导选项传递给 GRUB 中的内核，使用/bin/busybox shas init引导系统。³这与更常见的（或）获取根 shell的技术基本相同，但使用而不是常规的，因为它是动态链接的并且需要。init=/bin/busybox shinit=/bin/shinit=/bin/bash/bin/busybox sh/bin/sh/bin/shlibc.so.6

如果您想这样做，请在（重新）引导时按住左键Shift，以便出现 GRUB 引导菜单。（如果Shift不起作用，请使用Esc。）使用箭头键，选择Ubuntu 的高级选项，然后按 Enter。在此之后，您将不会按Enter，因为这将正常启动，而不是使用自定义启动选项。选择任何内核并按下e以临时编辑其引导选项。如果有多行并且您的光标不在以 开头的行上linux，请使用箭头键将其移动到那里。添加init=/bin/busybox sh到该行的末尾并按下F10以启动它。

您应该得到一个 BusyBox shell 提示符。您必须重新挂载根文件系统读写并重命名libc.so.6，以便它具有以前的正确名称。为此，请在 BusyBox shell 中运行这些命令（在libc.so.6不同位置的其他读者必须调整传递给cd命令的目录名称）：

mount -o remount,rw /
cd /lib64
mv libc.so.6.bak libc.so.6

然后我建议您将所有缓存的写入同步到文件系统，以只读方式重新挂载它，然后重新启动：

sync
mount -o remount,ro /
reboot -f

（没有-f，该reboot命令在这种情况下根本不起作用，因为没有适当的 init 守护程序正在运行。）

⁰ _{对于那些感兴趣的人：当那些程序（sudo如 但是当您运行它们时，在它们执行此操作之前，当它们确定是否应该允许您执行您要求的操作时，它们的有效用户 ID 是 root 的，而他们的真实用户 ID 仍然是您的。我提到这一点是为了解决一个常见的误解，即真实有效的用户 ID 在程序中的工作方式，例如sudo；如果您从未听说过真实有效的用户 ID，请随意忽略此脚注。}

¹ _{如前所述，busybox在 Ubuntu 中是静态链接的，不依赖libc.so.6. 您可能认为您可以使用它来避免重新启动，因为busybox它提供了一个su命令。但是，这无济于事，因为它在安装时busybox不是 setuid root。要实际工作以允许非 root 用户成为 root，su 必须是 setuid root。的有用功能busybox su是允许root冒充其他用户，而不是允许其他用户冒充root。}

² Zanna 对这个程序做出了巨大贡献，并且还为它做了所有的测试！

³ _{即使您可能希望它被解释为后续的内核引导选项，它也会成功传递sh给。busybox包括引号会阻止它工作。还要注意，在 Ubuntu 中，静态链接的busybox可执行文件只是被调用busybox，而不是 busybox-static（尽管提供它的包被调用busybox-static）。如果您卸载了静态链接的 BusyBox 并安装了动态链接的 BusyBox，那么此方法将不起作用，但您不太可能这样做。}

我知道root密码，所以应该有办法让我打开root shell，但似乎我不能。

您不能使用 root 密码，因为（通过重命名 libc）您破坏了可以使用它的所有“正常”方式，包括getty在另一个文本控制台上登录。如果您有一个静态链接的 su 或 sudo，您可以使用它来运行busybox mv，或者（在获得工作 root shell 的一般情况下），使用

LD_PRELOAD=whatever LD_LIBRARY_PATH=whatever static-su --preserve-environment将此自定义环境传递给以 root 身份运行的 bash

Setuid 二进制文件本身不能信任运行它们的用户提供的环境，但是（如果它们工作）可以在您请求时传递环境，并且您知道验证该操作的正确密码。

但是由于您没有静态 setuid 二进制文件可以验证您的请求以将自定义环境传递给运行 as 的进程root，因此您应该只使用您的物理访问权限重新启动到允许您修改根 FS 的环境。例如 DVD 或 USB 记忆棒，或使用init=/bin/busybox sh(参见@Eliah 的回答) 引导您的常规系统。

如果您没有恢复媒体，请在另一台计算机上创建可启动的东西，使用 Ubuntu 实时映像或适合修复各种操作系统和运行硬件诊断的多个恢复启动映像之一（这里有 5 个不同的评论那些）。（这些通常比实时的 Ubuntu 小，例如在 USB 记忆棒上仅占用大约 700MB。）

您可以将 USB 记忆棒设置为可使用其中之一（或 Ubuntu）启动，同时仍可以将其用于正常文件存储；您不需要将整个 USB 记忆棒专用于可启动映像。（不过，创建 live USB 记忆棒的最简单方法会破坏以前的内容，有时甚至无法用于存储文件。）

另一种选择是让 initramfs在执行pivot_root和执行init=您在内核命令行上传递的之前放入 shell。这不依赖于根 FS 本身的任何内容。您可能根本没有编辑器，但您确实有cat和重定向，以及 mv 和 ln。( cat > /mnt/root/etc/something)。如果您需要解决的问题很重要，您可能应该启动更强大的东西！

这在某些引导失败的情况下会自动发生，例如，如果 RAID 检测失败或导致根 fs 没有首先挂载（甚至是只读的）。（Ubuntu 15.10 - 每次启动时都会出现“BusyBox 内置 shell (initramfs)”）

在break=bottom完成大多数工作（加载模块并以只读方式安装根 FS）之后，但在执行真正的init. break=premount提前停止；请参阅该链接或/usr/share/initramfs-tools/init了解更多详细信息。

我在基本操作系统上解决了这个问题，方法是制作一个包含我拥有的基本操作系统版本的可启动驱动器，然后实时启动它。

启动 liveusb 后，我将文件夹 /lib 复制到有故障的基本操作系统 /lib 文件夹中，并通过保留最近的文件进行合并。

这对我有用。希望它也适合你。