当Ubuntu要求输入管理员用户的密码时，它如何决定要求哪个管理用户？
我正在设置一台将由几个人使用的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 -
PolicyKit的
第一个用于显式运行带有sudo或命令用gksu包装的菜单项（如Synaptic Package Manager ）。
在这种情况下，所需的密码是调用用户的密码，通常是用户登录的密码。
当PolicyKit感知应用程序尝试执行特权操作时，使用第二个。 在这种情况下，应用程序会询问PolicyKit Local Authority（通过D-Bus）是否可以执行操作。 然后，Local Authority通过Authentication Agent要求活动用户certificate其身份。 对话框窗口如下（不幸的是意大利文本:)
您可以从小黑三角标签和标签详细信息中识别PolicyKit。 如您所见，如果admin组中有多个用户，您可以从列表中选择要用于身份validation的用户。
鉴于所有这些， sudo和PolicyKit相对于可以实现的配置要复杂得多：您可以配置可以在没有密码的情况下执行的操作，仅由特定用户或组执行等。
回到你的问题，当应用程序使用的机制是PolicyKit时，独立于当前登录的用户，所需的密码将是Bob或Alice（只有两个管理员用户，如果我理解正确的话），你可以改变从列表中您要用于身份validation的用户。
当应用程序使用的机制是sudo （对于通过GUI执行的管理任务，这变得不那么频繁），您没有立即和简单的意思来选择用户进行身份validation。
显然，在这种情况下， sudo将是我的首选。 主要观点似乎是大多数（实际）管理员实际上并没有尽可能充分地使用/etc/sudoers （ User_Alias ， Runas_Alias ， Host_Alias ， Cmnd_Alias ）。
大多数管理员最终只使用一些现有规则并添加用户，或者更糟糕的是，只需将用户添加到sudo组中，Ubuntu设置（ %sudo …）上通常存在规则。 当然，这为各个用户提供了免费的统治和超级用户帐户的全部function。
鉴于你的评论：
所以我把它们添加到
/etc/sudoers
我估计你也不尽可能地使用它。
在像你这样的场景中，我会简单地编写Bob限制的几个动作的脚本。 实际上，这就是我在我维护的服务器上所做的，允许两个特定用户重新启动主机上的特定KVM来宾。 这些脚本将包含一个带有解释器绝对路径的hashbang（例如#!/bin/dash而不是#!/usr/bin/env bash ），并且可能运行在别处用于特权任务的shell（ /bin/dash或/bin/sh ）。 这些只是预防措施。 除此之外，我会确保将所有绝对路径硬编码到二进制文件并尽可能少地使用它们。 例如，当使用bash / dash我更喜欢builtin command s（参见man bash ）。 您可以通过为变量分配绝对路径并根据该变量引用程序（ $VIRSH而不是/usr/bin/virsh ）来使其可维护。 如果可以，请在调用之前审核任何外部脚本的代码。 特别是如果您需要在特权环境中调用它们。 在我的情况下，我还将用户限制在特定的根目录和特定的SSH子系统，因为它们只通过sshd和公钥认证连接到机器。 显然你不需要那个。
确保chown root: chown root: 以防止除了root任何人修补它。 还要注意在目标二进制文件上启用setuid和setgid位（ find可用于发现它们）。 我们暂时假设您的脚本位于/usr/sbin/priv-action 。
现在编辑/etc/sudoers 。 noexec可用于防止除明确允许的其他二进制文件之外的其他二进制文件。 实际上有很多其他设置，而不仅仅是我在这里描述的设置。 所以一定要咨询man sudoers 。
现在我更喜欢在我的sudoers文件中命名用户（ User_Alias ），但你也可以使用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 ）可以在所有主机上运行任何用户上下文，但会被要求输入密码（假设默认行为）。 在最后一个ALL之前添加NOPASSWD标记也将允许root在不被要求输入密码的情况下执行相同操作（如下所示： root ALL=(ALL) NOPASSWD:ALL ）。 ALL是各种别名类型的内在通配符别名。
但回到鲍勃：
LIMITED_ADMINS ALL=(root) PRIV_ACTION
将允许bob和其他列出的User_Alias LIMITED_ADMINS成员（在所有主机上，这就是ALL的用途）作为用户root （暗示组，但可以给出，请参阅man sudoers ）在Cmnd_Alias PRIV_ACTION给出的命令。 它变得更好了。 仍然假设您编写此脚本，您可以允许各种参数，从而避免编写多个脚本。 /etc/sudoers很乐意采用类似shell的通配符来限制允许传递的参数的可能性。
我一直发现管理员不会像应该使用的那样使用sudoers ，这就是为什么我赞赏两本书“Linux Server Hacks”和“Linux Server Hacks Volume Two”中的相应“Hack”，这让我开始了使用这个伟大的设施更复杂。
你可以想出各种令人费解的东西 – 这可能不完全有助于安全方面 – 为你的特定情况提供解决方案，但是一旦你说出/etc/sudoers的基本词汇，你就可以执行相当神奇的function:)
注意：请记住，如果你有这种倾向，你也可以在/etc/sudoers.d/下面创建一个新文件。 假设您的/etc/sudoers包含以下行：
#includedir /etc/sudoers.d
Unix / Linux中只有一个超级用户，它的名字是root，但sudoers是可以成为root用户。 你应该使用组：
newgrp admins
然后将用户分配给该组：
chgrp alice admins
然后将管理员组添加到sudoers配置文件，就好像该组是用户一样。
更新
或者您可以将任何用户添加到管理员组：
chgrp alice admin