mch*_*hid 34 users root permissions sudo
我认为拥有比 root 用户更高权限的用户可能是有利的。
你看，我想保留所有的活动和几乎所有现有的 root 用户权限，就像现在一样。
但是，我希望能够在极其孤立的情况下拒绝root 权限。
这样做的好处之一是可以防止在更新期间安装某些不需要的文件。这只是一种可能优势的示例。
因为 apt-get 更新是由 root 或以 sudo 权限运行的，所以 apt-get 能够在更新期间替换某些不需要的文件。
如果我可以拒绝这些特定文件的这些权限，我可以将它们设置为指向/dev/null或可能有一个空白占位符文件的 simlink，该文件可能具有拒绝在更新期间替换文件的权限。
此外，我不禁想起在接受其中一位 Ubuntu 创作者采访时所说的一句话，当时他说用户如何更好地信任“我们”（指的是 Ubuntu 开发者）“因为我们有 root " 这是对如何使用 root 权限执行系统更新的参考。
简单地改变安装过程来解决这个问题绝对不是我在这里感兴趣的。既然我已经对拥有拒绝 root 访问权限的想法有了一种品味，我想找出一种方法来实现这一点，只是为了做到这一点。
我只是想过这个，到目前为止还没有花任何时间在这个想法上，我相当有信心可以解决这个问题。但是，我很想知道这是否已经完成，或者这是否可能不是一个新想法或概念。
基本上，似乎应该有某种方法可以让超级超级用户拥有超出系统权限的权限仅一级。
注意：虽然我觉得接受的答案最符合标准，但我真的很喜欢@CR 的答案。还。
我想在树上创建一个实际用户（我），但我想我只需要在有一天我有时间弄清楚的时候坐下来。
此外，我不是要在这里选择 Ubuntu；如果我对它感到消极，我不会将它用作我的主要发行版。
Hau*_*ing 84
您想要的“用户”称为 LSM：Linux 安全模块。最著名的是 SELinux 和 AppArmor。
通过这种方式，您可以防止某些二进制文件（及其子进程）执行某些操作（即使它们的 UID 是root）。但是您可以允许这些操作getty及其子进程，以便您可以手动执行。
And*_*ndy 50
你误解了root用户的概念。
用简单的英语来说，root是在“树的顶端”。
如果你决定有一天拥有一个“超级超级用户”，然后下个月拥有一个“超级超级超级用户”（！）怎么办。你想在树上“向上”多远？您将如何调整所有权限和层次结构以使其工作？谁总是在顶端？必须有人在顶部，而且是root。故事结局。
这里给出的解决方案——包括 AppArmor 和 SELinux——并没有真正改变这一点。它们只是允许对root权限和进程进行更精细的控制。
在我看来，您的更新过程不适合预期的结果。但这根本不是root用户的错。与其将事情复杂化，root不如将其视为最高级别的权限用户，然后是其他一切，您必须向下工作。
我知道有些人会对此进行标记，但用户层次结构中没有更高的级别，所有其他解决方案只是对root权限的工作方式提供了略微不同的控制。但是他们不会创建新用户，具有更高的权限。
您不能拥有“更多权限”的用户，root因为root代表可能的最高权限级别。使用“比 root 更能控制”这样的短语是一个矛盾 -root拥有完全控制权和所有可能的权限，因此在它之上无能为力。
CR.*_*CR. 26
如果您只想防止文件或目录被更改/删除，那么只需在它们上设置不可变标志。
chattr +i <file>
除非该标志被移除，否则即使是 root 也无法对它们做任何事情。也可以使用容器/命名空间系统来防止 root 访问，但这对于您所需要的来说似乎有点过分了。
您可以限制 root，而不是拥有超级超级用户。请参阅 在 gnu/linux 上设置文件权限等的不同方法有哪些
还有 AppArmor 和 SELinux。
和/或 configure sudo，这样您就不会放弃完整的 root 权限。您可以对其进行设置，以便用户只能使用预先同意的参数运行预先同意的命令。
您还可以使用虚拟化来限制 root：
另请参阅etckeeper：此工具修订版控制/etc目录，并与 apt 同步。默认情况下它不安全，恶意安装可能会破坏它，但您也可以让它将更改推送到防火墙备份存储库。
一般使用修订控制，带有防火墙备份存储库。这有助于防止意外、故意损坏和硬件故障。
防火墙备份存储库可以位于不同的机器上、互联网上或不同的虚拟机（或虚拟机主机）上。
对于像APT这样的软件，在正常运行时需要访问几乎所有系统，限制是有问题的。即使你阻止它访问系统的某些部分，恶意分发者很可能有足够的可能性来解决。例如，通过替换库或仅替换二进制文件或添加恶意配置更改，最终将使用不受限制的 root。
根据您设置限制的程度，某些安装脚本可能会中断。
对于限制应用程序和用户的方法，您可以编写 AppArmor 或 SELinux 策略。这样的策略哪个更受支持取决于您的发行版：基于 Debian 的对 AppArmor 的支持更好，而基于 Fedora/RHEL 的发行版默认启用 SELinux。
AppArmor 和 SELinux 都适用于白名单策略，其中包含允许（或拒绝）特定操作的规则。策略在exec应用到进程，类似地，当策略在登录时应用到他们的进程时，用户可能会受到限制。一个深思熟虑的策略是无法绕过的（如果不考虑内核错误）。以 root (uid 0) 身份运行的受限进程受配置策略的限制，除非策略中明确允许，否则无法更改它。
AppArmor 策略语言定义了一个拒绝规则，可用于构建黑名单策略。开始使用 AppArmor 的一个好地方是 AppArmor手册页、wiki并在/etc/apparmor.d/.
SELinux wiki 中提供了大量 SELinux 管理和开发材料。SELinux参考策略托管在 github 上。
我不敢相信没有人提到 apt pinning...
几年前，微软发布了一个补丁，使 Windows 10 机器无法与我们旧的 Samba NT4 域控制器通信。发现问题后，我们将 Samba 包固定在当前版本上，并且apt仍然可以正常运行。
完整的Debian 演练很好地解释了这个过程：
在/etc/apt/preferences（或下的新文件/etc/apt/preferences.d/）中，添加一些文本以指定哪个包和版本：
Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900
检查文档以了解确切的语法，但这是我们固定软件包版本的快速而肮脏的方式。Root可以绕过它，因为 root 总是可以做到的，但这解决了包管理器试图自动升级你的包的问题。
注意：此答案假设您有XY 问题
其实很简单。
Root 是你的“超级超级用户”
创建一个名为“admin”的帐户，并授予他所有 root 权限，除了您不想要的权限。
然后创建一个名为 bob 的用户，并让他“成为管理员”。通过使用 su 甚至 sudo。
现在你有一个普通用户 (bob) 一个可以做管理工作的超级用户 (admin) 和一个超级超级用户 (root)。
如果您想将名称“root”更改为其他名称，您甚至可以这样做。从技术上讲，只有用户 ID (0) 很重要。