它是一个生产服务器 - CentOS 6.1
某些过去具有 root 访问权限的用户登录到服务器并从 /bin/su 文件中删除 SUID 位，然后退出 root。现在我们无法切换回root。另外，服务器上禁用了 root 的 ssh 访问，因此 root 无法直接登录机器。由于我们既无法 su 到 root，也无法以 root 身份 ssh，所以我们无法为 /bin/su 文件设置 suid 位。（而且我们无法使用 su 在用户之间切换）
本来应该怎样：
$ ll /bin/su
-rwsr-xr-x. 1 root root 30092 Mar 10 2011 /bin/su
现在怎么样：
$ ll /bin/su
-rwxr-xr-x. 1 root root 30092 Mar 10 2011 /bin/su
有什么方法可以切换回 root 或以任何方式设置 SUID 位吗？
笔记：我们希望避免重启无网络用户模式，因为服务器 24x7 全天候使用，停机有点困难。如果可以重启，那么我们只需以 root 身份使用单用户模式登录并重置该位即可。
请随意给出有创意的答案。我可以在我们的测试环境中测试您的答案。
答案1
一些选项：
sudo -i，这是最明显的选择。sudo -l然后寻找一个允许您使用的命令来解决问题，例如：编辑由 root 执行的文件，例如 crontab、logrotate、executon yum/rpm...- 转到控制台，并以 root 身份连接（如果我理解的话，只有 ssh 受到限制）
- 打开图形会话，某些发行版具有不依赖 sudo 的 root 工具。另外，他们中的许多人都有一些更新管理器..也许您可以重新安装提供的软件包
su - 如果你有像puppet/chef/ansible/fai这样的配置管理工具...推送配置！
- 检查您的 crontab 以查看是否可以编辑文件以升级。
- 如果您的服务器连接到中央身份验证系统（尤其是LDAP/nis），请创建一个具有高权限的帐户（组轮，或用户uid = 0）。
- 如果它是虚拟服务器，请将其关闭，然后挂载并编辑文件系统。
一些银弹：
- 以单用户模式（red hat）重新启动服务器或指定
init=/bin/sh（Debian 和 rhel/CentOS 7），然后修复权限。 - 在 CD/DVD/USB/NetBoot 中重新启动服务器并使用恢复（或仅安装和编辑）
还有一些真的很难看：
- 找到您系统中的漏洞来危害它！
如果您的系统管理员做得很好，普通用户就无法做任何这些事情（但您是系统管理员）
答案2
假设您所在的组允许您执行以下操作sudo：
sudo -i
将为您提供root访问权限并允许您进行修复/bin/su。请记住，您使用的用户密码是sudo- 而不是 root 的密码。
答案3
该问题暗示 SSH（或同等方式）是唯一的访问方式。通常从用户特权进程获取 root 特权的唯一方法是通过su、sudo或其他站点本地替代方案。如果您没有，那么您可能会运气不佳，因为替代方案的存在表明存在某种安全漏洞。
也就是说，重新启动以获得访问权限的建议表明可以以某种形式进行控制台访问。一般来说，root 可以直接在控制台上登录，并且是首先要尝试的（也许可以使用 IPMI 或 IP KVM 远程登录？）。图形控制台和串行端口都值得尝试。
另一种方法是寻找已安装或可以安装的外部文件系统，并允许提供静态 setuid su 二进制文件供用户运行。
如果存在配置管理系统（puppet、chef 等），那么它可能仍在运行并可用于修复或更新二进制文件。
如果正在运行的系统是虚拟机，您可以从主机环境以某种形式访问它。 （相反，如果它是主机，您可能能够利用虚拟机上的 root 访问权限来获得控制权）
之后，首先评估值得花费多少时间来重新访问系统而不重新启动。然后，如果时间合理，就需要考虑一下您可以访问哪些内容。查看其中每一个并评估它们修复 set-uid 位或以其他方式运行相对任意命令的能力：
- 您的用户可以访问系统上的每个 set-uid 二进制文件
- 以 root 用户身份运行的每个进程（查看预期用途）
- 底层存储系统及其替代访问
- 以 root 用户身份运行的每个进程（寻找未修补的本地代码执行漏洞）
- 内核版本（寻找未修补的代码执行漏洞）
在某些时候，它实际上变成了安全审计。
答案4
您也可以使用此命令：
须藤-s
它会给你 root 访问权限