☰

ID 结果因询问者而异

tag-icon • tag-icon root usermod
ID 结果因询问者而异

我的 userX 通过实时组拥有实时权限。我想给该用户管理员权限，所以我切换到 root

~>su root

然后跑了

#>usermod -a -G root userX

短暂的延迟后我回到提示并测试了效果。

#>id userX
#>uid=1000(userX)  gid=0(root) groups=0(root),1001(realtime)

那么看来我是成功的。我退出并通过添加虚拟用户来测试我的新管理员。

#>exit
~>useradd BSD
bash: /usr/sbin/useradd: Permission denied

有问题。我尝试验证我的群组成员身份，它给了我不同的答案。

~>id
~>uid=1000(userX)  gid=1001(realtime) groups=1001(realtime) contextunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

所以，我需要知道为什么我的用户说它不是 root 的一部分，而 root 却说用户是。我缺少什么？

答案1

发生了什么？

用户所在组的列表仅在登录时设置（并且可能通过使用很少使用的sg命令进行修改，但仅当为该组设置了组密码时才有效）。如果该用户注销，然后重新登录，他们应该会在该组中看到自己。然而，处于 GID 0 的组中（大多数 Linux 系统上的“root”，大多数非 Linux 系统上的“wheel”或“adm”）并不等同于拥有管理权限，而且实际上对于安全角度。

为什么这与行政权限不同？

root 用户（UID 0）很特殊。根组（GID 0，wheel由于我似乎找不到的历史原因在许多非 Linux 系统上调用）不是。您的用户将能够访问 root 组拥有的文件，但可能没有其他权限。这是一个有点复杂的区别，但却是一个非常重要的区别。

为什么这是一个坏主意？

这是一个坏主意，其原因与始终以 root 用户身份运行是一个坏主意几乎相同。你总是差一个错误就导致系统无法使用（例如，在大多数 Linux 系统上，成为 root 组的一部分意味着你可以轻松地使系统无法启动，因为你可以删除其中的内容/boot）。

授予该用户管理权限的正确（且安全）方法是什么？

如果可能，请设置sudo或系统上现有的doas任何其他权限提升工具以允许他们访问。su如果您除了 之外没有这样的工具su，请安装一个（我建议sudo，它是使用最广泛的工具，因此也是最容易学习的工具之一，因为有很多文档）。如果这也不是一个选项，那么su当您需要执行管理任务时直接提升是正确的选择（尽管这样做要小心，因为su不会正确重置通过它调用的命令的环境）。

相关内容