政策机制答案

【问题标题】：policy and mechanism政策机制
【发布时间】：2011-06-14 15:29:18
【问题描述】：

我在阅读我的操作系统教科书时遇到了“分离机制和策略”的概念。我不确定这意味着什么，所以我查看了我必须承认的维基百科，但也没有太大帮助。

机制与分离 policy[1] 是一个设计原则计算机科学。它指出机制（系统的那些部分实现控制操作授权和资源分配）不应该规定（或过度限制）政策依据哪些决定进行了哪些操作授权，以及哪些资源分配。

有人能缓和一下，如果可能的话，用几个例子解释一下separation of mechanism and policy在操作系统上下文中的含义？

【问题讨论】：

【解决方案1】：

这对 X-Windows 系统意味着什么。

X-Windows，在最底层，提供了一种操作屏幕区域的方法，称为“窗口”。它还提供了一种接收窗口内发生的事件的方法。

但是 X-Windows 没有提到标题栏、菜单、滚动条或任何类似的东西。它也没有说明特定应用程序可以使其窗口占据整个屏幕或何时必须将窗口移出屏幕的规则。它确实为一个应用程序提供了一种方法来强制其他应用程序在使用顶级窗口执行操作之前询问它的权限，但不提供任何此类应用程序作为基础服务器的一部分。

X-Windows 是关于机制，而不是策略。

该策略由小部件工具包、窗口管理器以及稍后添加到系统的其他东西提供。例如，许多小部件工具包使用一组重叠的子窗口作为滚动条，并为这些子窗口请求鼠标事件，以便它们可以检测点击和拖动操作并使子窗口做出适当的响应。

这就是为什么 GNOME 和 KDE 可以在同一个显示器上相处，以及为什么对面板或桌面一无所知的旧 X-Windows 程序仍然可以在现代系统上正常工作的原因。

【讨论】：

【解决方案2】：

对于*nix操作系统，一般的思路是安全系统由内核实现，授权系统由用户空间实现。

许多人嘲笑（无论是公正的还是其他的）全能的 root 和 suid 二进制文件是有效分离所必需的。可以完全替换身份验证机制，同时保持安全性不变（ssh 会这样做，这就是它在 Windows 上使用未记录 API 的原因）。

【讨论】：

+1 - 该原理的另一个很好的例子。 Unix 实际上有几乎（但不完全）足够的机制来实现基于能力的安全性。通过 Unix 域套接字传递的文件描述符是一件基本的事情，这是一个非常重要的特性。但它还需要更多，比如让用户进程访问exec 并让生成的进程拥有更少的权限。
@Omnifarious：实际上最后一个很简单。删除 fork() 和 exec() 之间的权限。但是，没有与 Vista 的沙盒等效的功能。
但是如果你是一个用户进程，你如何放弃权限呢？例如，拥有 'nobody' 的权限并且没有创建套接字的权限。而且Vista的沙盒可以通过文件描述符传递来实现。
我曾经遇到过一个可以限制子进程可以发出的系统调用的东西，但是我忘记了它的名字，现在找不到了。
有能力机制——尽管目前看来是特定于 Linux 的。 Linux 已经实现了与功能相关的现已失效的 POSIX/SUS 草案标准，并且现在从内核 2.6.24 开始完全符合该标准。在 linux 系统上，它记录在 man 7 功能下。我目前在我正在开发的 httpd 守护程序中使用 libcap api，以及 epoll api，它也是 linux 特定的。

【解决方案3】：

虽然这是一个很老的问题，但我还是想分享一下我的观点。

这段话之所以让人迷惑，是因为“机制”和“政策”这两个词。在软件工程的背景下，我认为将“机制”替换为“接口”，将“策略”替换为“实现”总是可以的。

关于接口和实现的分离，如果你是用Java编程的，那么你一定对这两个概念很熟悉。通过这样做，我们可以将“做什么”与“怎么做”隔离开来，这有助于我们实现系统解耦。

为什么要解耦？解耦提高了代码的可扩展性和可维护性，这意味着我们可以在需求变化时编写更少的代码:)

了解有关从“GoF 设计模式”中解耦的更多技术。

【讨论】：

【解决方案4】：

机制与政策的区别 机制决定怎么做，政策决定做什么。

策略与机制的分离是非常重要的原则，如果以后要更改策略决策，它可以提供最大的灵活性。

【讨论】：