K.I.S.S. – 简单哲学 Linux, Freedom, Arch, Python, Gtk+, C … Keep It Simple, Stupid!

使用 PolicyKit 进行身份认证（下）

PolicyKit 的配置文件
分析完了 PolicyKit 的机制，我们来看一下它的配置文件是如何书写的。
PolicyKit 的配置文件藏在哪里呢？我们来进入/usr/share/PolicyKit/policy这个目录，怎么样，是不是看到很多.policy文件？（不要告诉我你没装 PolicyKit ……）
好的，打开其中的org.freedesktop.hal.storage.policy这个文件，你可能会看到下面的内容：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">

<policyconfig>

 <action id="org.freedesktop.hal.storage.mount-fixed">
 <description>Mount file systems from internal drives.</description>
 <message>System policy prevents mounting internal media</message>
 <defaults>
 <allow_inactive>no</allow_inactive>
 <allow_active>auth_admin_keep_always</allow_active>
 </defaults>
 </action>

 <action id="org.freedesktop.hal.storage.mount-removable">
 <description>Mount file systems from removable drives.</description>
 <message>System policy prevents mounting removable media</message>
 <defaults>
 <allow_inactive>no</allow_inactive>
 <allow_active>yes</allow_active>
 </defaults>
 </action>

</policyconfig>

我们来依次分析一下：

  id：id 是对 PolicyKit 中 Action 的唯一标识，可以看到，各个域从大到小，用圆点分隔。从下图我们可以看出，这是一种树形结构。



description：这个是注释，没什么好说的，让读配置文件的人知道这个选项的意义。  message：这个就是前面提到的说明字符串了，强烈推荐写上，让使用者明白他在验证什么操作，以免引发安全隐患。  defaults：关键的地方到了！这里可以写上对于请求者是否为活动状态的三种情况（allow_any、allow_inactive、allow_active）返回的值。  可以返回的值有以下几种：
      no
      auth_self_one_shot
      auth_self
      auth_self_keep_session
      auth_self_keep_always
      auth_admin_one_shot
      auth_admin
      auth_admin_keep_session
      auth_admin_keep_always
      yes
这个实在没有什么可说的，它们的作用从字面上理解就可以了……如果不懂还是好好学学英语吧……
好了，说了这么多，可能大家还是不知道怎么使用 PolicyKit 编程吧？其实最简单的办法还是看手册啊！什么，你想要例子？看下这里吧！呵呵，相信懂得原理的你，再看这个例子的时候就不会那么吃力，很快就能应用 PolicyKit 进行编程了吧？
（全文完）

使用 PolicyKit 进行身份认证（中）

PolicyKit 的运作流程
在上次的图中，我们可以看出 PolicyKit 运作过程中的几个要素：请求发出者（gnome-mount），请求目标（磁盘），请求的动作（挂载）。下面我们来看一下 PolicyKit 的运作流程。

图一：用户点击了磁盘图标，系统通过 DBus 发送请求给 HAL。
图二：HAL收到并验证请求（请求被包装在一个叫做 PolKitCaller 的对象中，包含 uid 、 pid 、会话标识符、会话是否为活动状态、是否远程、远程地址和其他可选信息），并据此构建了 PolKitCaller 对象，之后，HAL 会调用 libpolkit 中的函数 polkit_context_can_caller_do_action () ，并把以上两个结构体作为参数。
根据这个函数传递来的参数，系统会到 PolicyKit 的配置文件（关于配置文件，会在下次说明）中进行验证，根据配置文件的返回值和验证数据库中的内容决定是否允许请求的操作。
可能的返回值有三种：通过（POLKIT_RESULT_YES）、拒绝（POLKIT_RESULT_NO）、需要验证（POLKIT_RESULT_AUTH 系列）。返回值被包含在一个叫做 PolKitResult 的结构体中。
图三：当返回值不是 POLKIT_RESULT_YES 时，HAL 把这个返回值外加之前所请求的操作一起返回给请求者。
图四：如果返回值是 POLKIT_RESULT_AUTH 系列（例如 POLKIT_RESULT_AUTH_ADMIN_KEEP_ALWAYS），顺带返回的还有定义在配置文件里的说明字符串（这样可以识别你正在验证的是什么动作）。
现在文件管理器知道想要随便挂载一个磁盘是不行的了，只好向 Authentication Agent 求助，说：”快快！帮我做个验证窗口出来！“顺带把刚才 HAL 发给它的 PolKitResult 和 PolKitAction 发给它。
图五：Authentication Agent 收到请求，也跟图二中的 HAL 一样，先验证一下传来的东西是否正确，构建个 PolKitCaller 去配置文件那里验证一下，检查 PolKitResult 是否和文件管理器传过来的一样。
然后 Authentication Agent 听话地构建一个验证窗口，包含之前返回的说明字符串。
图六：如果验证成功，它会让 HAL 去重新请求一下。此时因为验证成功，验证数据库中已经允许了此程序，当然验证通过了！
下次我们来分析一下 PolicyKit 的配置文件。

使用 PolicyKit 进行身份认证（上）

（为了说明方便，文中很多地方使用了 PolicyKit 官方文档中的图片。这篇文章并不是官方文档的翻译，想要获得更加全面的说明，请参见这里。）
什么是 PolicyKit
PolicyKit 是什么呢？之前发帖子的时候并没有弄清，以为是一个可以用来获得 Root 权限的东西，经过 TualatriX 兄的指点，才发现根本不是那么回事。
PolicyKit 是一种应用程序本身或者应用程序之间验证身份的机制，验证通过，你就可以执行所请求的操作，否则没门。这样说来对于没有什么安全隐患的功能是用不到它的，比如我的 CugbFreer，需要的只是调用 libpcap 进行流量统计，实在看不出什么危险，验证反而麻烦。不过既然之前已经说了要写一篇，那还是简单说说吧。
为什么要使用 PolicyKit
这个看起来像是对大多数人没用的机制，但是事实并非这样，只要仔细想一下，就可以挖掘出它的用途。
比如说，nautilus 里挂载磁盘，不知道你是否留意过，第一次使用的时候，点击一个未挂载的磁盘，就会弹出 PolicyKit 验证的界面。
我们知道，磁盘的自动挂载是靠 HAL 控制的，在 HAL 上面还有 gnome-mount，当你点击 nautilus 里的未挂载磁盘时，就会调用 gnome-mount。可是 gnome-mount 只是一个用户程序，而非特权（privileged）程序，如何能够“请”得动 HAL 呢？
与其主动去请，还不如 HAL 给我们提供一个特权接口，只需要验证一下身份，就可以调用 HAL 的特权方法，来挂载和卸载设备，并且系统可以记住这种特权，这样下次你挂载的时候，就不需要验证了！是不是很方便？

当然，当很多程序都需要一种验证机制、又不想自己去实现的时候，一种统一的机制 PolicyKit 诞生了。
（小提示：PolicyKit 还有哪些应用呢？我们比较熟悉的有 Network Manager 、Gnome 面板的时间控件、Ubuntu-tweak 等等。通常是在界面上加一个“解锁”键，点击时就会触发验证，以执行特权功能。）