当 Ubuntu 询问管理员用户的密码时，它如何决定询问哪个管理员用户？
Bri*_*ell 11 root administration users
我正在设置一台可供多人使用的 Ubuntu (10.10) 机器。它是小型办公室中的共享机器。它的主要角色是使用 VirtualBox 托管虚拟机并使用 Samba 提供文件。
对于 Samba，需要设置多个用户帐户，以便不同的人可以从他们自己的工作站连接到 Samba 共享。但是，还有一个专门用于运行虚拟机的帐户，供多人使用。有时人们会尝试使用此帐户执行需要提升权限的操作 - 这会导致 Gnome 的“请输入管理用户的密码”对话框弹出。但是，此对话框需要我的密码 - 当我设置机器时，我的帐户是创建的第一个帐户，因此似乎假设我是唯一被授予 sudo 权限的用户。
我想指定另一个用户作为“首选管理员”，可以这么说，它不能是共享帐户用户，因为每个人都必须知道该帐户的密码，因此我希望对其权限进行严格限制。它不能是我的帐户，因为我无法将我的密码告诉其他人，而且我不会经常出现在网站上以自己输入密码。但是，有人可以亲自执行此操作，因此我将它们添加到/etc/sudoers. 我如何告诉 Ubuntu 当它需要提升某些东西的权限时，它应该首先询问他们的帐户？
总结一下：
- 机器上的帐户：Alice、Bob、Carol、Dave、Eliza。
- 安装 Ubuntu 时，Alice 是第一个用户，在安装过程中添加。
- “Dave”其实是很多人都在用的账号，
/etc/sudoers因为密码是公知的，所以进不去。 - Bob 已被设置为 Gnome 中的“管理”帐户并正确输入
/etc/sudoers- Bob 是该办公室的老板。 - 当以 Bob、Carol、Eliza 或 Dave 身份登录时尝试需要提升权限的操作时，系统应请求 Bob 的凭据。
- 当以 Alice 身份登录时尝试需要提升权限的操作时，系统应该请求 Alice 的凭据（尽管 Alice 有点像 buckaroo 系统管理员，并且习惯于
su -执行扩展管理任务）。
我需要进行哪些配置更改才能在此处实现所需的状态？
首先让我们指出，通过两种不同的机制允许非 root用户进行特权操作。
sudo政策工具包
当您显式运行命令sudo或菜单项时使用第一个，其命令被包装gksu（如Synaptic Package Manager）。
在这种情况下，所需的密码是调用用户的密码，通常是登录的用户。
当 PolicyKit-aware 应用程序尝试执行特权操作时使用第二个。在这种情况下，应用程序会询问 PolicyKit Local Authority（通过 D-Bus）是否可以执行该操作。然后，本地管理机构通过身份验证代理要求活动用户证明其身份。对话框窗口如下所示（不幸的是，文本为意大利语:)
您可以从黑色小三角形和标签Details 中识别 PolicyKit 。如您所见，如果组中有多个用户admin，您可以从列表中选择用于身份验证的用户。
鉴于所有这些，sudo就可以实现的配置而言，PolicyKit 和 PolicyKit 都复杂得多：您可以配置无需密码即可执行的操作，仅由特定用户或组执行等。
谈到您的问题，当应用程序使用的机制是 PolicyKit 时，独立于当前登录的用户，所需的密码将是 Bob 或 Alice 的密码（如果我理解正确，只有两个管理员用户），您可以更改从您要用于身份验证的用户列表中。
当应用程序使用的机制是sudo（对于通过 GUI 执行的管理任务，这种机制变得不那么频繁）时，您没有立即和简单的方法来选择用户进行身份验证。
显然，sudo在这种情况下，将是我的首选。主要的一点似乎是大多数（实际）管理员实际上并没有/etc/sudoers最大限度地使用( User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias)。
大多数管理员最终只使用一些现有规则并添加用户，或者更糟的是，简单地将用户添加到sudo通常在 Ubuntu 设置中存在规则的组 ( %sudo...)。当然，这赋予了各自用户自由支配权和超级用户帐户的全部权力。
鉴于您的评论：
所以我将它们添加到
/etc/sudoers
我想你也尽量不要使用它。
在像您这样的场景中，我会按照字面意思编写限制 Bob 执行的少数操作。事实上，这就是我在我维护的服务器上所做的，以允许两个特定用户重新启动主机上的特定 KVM 来宾。脚本将包含一个带有解释器绝对路径的 hashbang（例如，#!/bin/dash而不是#!/usr/bin/env bash），并且可能与在其他地方用于特权任务（/bin/dash或/bin/sh）的shell 一起运行。这些只是预防措施。除此之外，我会确保对二进制文件的所有绝对路径进行硬编码，并尽可能少地使用它们。例如，在使用bash/ 时，dash我更喜欢builtins 而不是commands（请参阅man bash）。您可以通过为变量分配绝对路径并引用基于该变量的程序（$VIRSH而不是/usr/bin/virsh）。如果可以，请在调用任何外部脚本之前检查它们的代码。特别是如果您需要在特权上下文中调用它们。就我而言，我还将用户限制在特定的根目录和特定的 SSH 子系统中，因为他们仅通过sshd公钥身份验证连接到机器。显然你不需要那个。
确保chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>防止任何人root修改它。还要小心在目标二进制文件上启用setuid和setgid位（find可用于发现它们）。让我们暂时假设您的脚本驻留在/usr/sbin/priv-action.
现在编辑您的/etc/sudoers. noexec也可用于阻止除明确允许的二进制文件之外的其他二进制文件。实际上还有很多其他设置，而不仅仅是我在这里描述的那些。所以一定要咨询man sudoers。
现在我更喜欢User_Alias在我的sudoers文件中命名用户 ( ) ，但您也可以使用Group_Alias( man sudoers) 或实际系统组 (例如%sudo)：
# The list is comma-separated: bob,alice,...
User_Alias LIMITED_ADMINS=bob
然后添加一个命令别名以允许执行该特定脚本：
# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias PRIV_ACTION=/usr/sbin/priv-action
最后但并非最不重要的是允许bob（或者更确切地说是下面列出的用户LIMITED_ADMINS）通过脚本执行特权命令的魔法线：
LIMITED_ADMINS ALL=(root) PRIV_ACTION
与之前的别名定义不同，该行需要解释。因此，让我们首先深入研究“用户规范”行的含义。这里有man sudoers帮助：
用户规范的基本结构是
who where = (as_whom) what.
示例行（可在大多数 Ubuntu 设置中找到）：
root ALL=(ALL) ALL
这表示名为 root（用于#0将其绑定到 UID 0）的用户可以在所有主机上在任何用户上下文下运行任何内容，但会被要求输入密码（假设默认行为）。NOPASSWD在最后一个之前添加标签ALL也允许root在不需要密码的情况下执行相同的操作（如下所示：）root ALL=(ALL) NOPASSWD:ALL。ALL是各种别名类型的固有通配符别名。
但回到鲍勃：
LIMITED_ADMINS ALL=(root) PRIV_ACTION
将允许bob和其他列出的成员以用户身份（隐含的组，但可以给出，请参阅）User_Alias LIMITED_ADMINS运行（在所有主机上，这就是ALL它的用途）在. 它变得更好了。仍然假设您编写此脚本，您可以允许各种参数，从而避免编写多个脚本。很高兴使用类似 shell 的通配符来限制允许传递的参数的可能性。rootman sudoersCmnd_Alias PRIV_ACTION/etc/sudoers
我一直发现管理员不使用sudoers它应该使用的方式，这就是为什么我欣赏两本书“Linux Server Hacks”和“Linux Server Hacks Volume Two”中各自的“Hack”，这让我开始了更复杂地使用这个伟大的设施。
您可以想出各种复杂的 - 这可能对安全方面没有帮助 - 针对您的特定情况的解决方案，但是一旦您说出基本词汇，/etc/sudoers您就可以执行非常神奇的壮举:)
注意：请记住，/etc/sudoers.d/如果您愿意，也可以在下面创建一个新文件。这假设您/etc/sudoers包含以下行：
#includedir /etc/sudoers.d