Linux 政策和机制

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

机制与机制的分离 策略[1]是应用程序中的一个设计原则 计算机科学。它说 机制（系统的那些部分） 控制 业务授权和 （资源分配）不应 命令（或过度限制）该命令 决策依据的政策 是关于要执行哪些操作的 授权，以及授权哪些资源 分配

---

有人能不能小声点，如果可能的话，用几个例子解释一下机制和策略的分离在操作系统的上下文中意味着什么

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

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

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

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

---

例如，这就是为什么GNOME和KDE可以在同一个显示器上相处，以及为什么对面板或台式机一无所知的真正古老的X-Windows程序在现代系统上仍然可以正常工作。

关于*nix操作系统，一般的想法是安全系统是由内核实现的，授权系统由用户空间实现

---

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

虽然这是一个非常老的问题，但我仍然想分享我的观点

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

至于接口和实现的分离，如果您使用Java编程，那么您必须非常熟悉这两个概念。通过这样做，我们可以将“做什么”与“如何做”分离开来，这有助于我们实现系统解耦

为什么要脱钩？解耦提高了代码的可扩展性和可维护性，这意味着当需求发生变化时，我们可以编写更少的代码：）

---

了解更多与“GoF设计模式”脱钩的技术。

机制和政策之间的差异 机制决定怎么做，政策决定怎么做

---

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

+1-这一原则的另一个很好的例子。Unix实际上几乎（但不完全）有足够的机制来实现基于功能的安全性。通过Unix域套接字传递文件描述符是一项基本功能，这是一项非常重要的功能。但它需要更多的权限，比如一个用户进程执行

exec

，并使生成的进程拥有更少的权限。@Omnifarious:实际上最后一个很简单。删除fork（）和exec（）之间的权限。然而，Vista的沙箱并没有等价物。但如果你是一个用户进程，你如何删除特权？例如，具有“nobody”特权，并且没有创建套接字的权限。Vista的沙箱可以通过文件描述符传递来实现。我曾经遇到过这样一种情况，即可以限制子进程发出的系统调用，但我忘记了它的名称，现在找不到它。有一种功能机制——尽管目前看起来是Linux特有的。Linux已经实现了与功能相关的POSIX/SUS标准草案，并且从内核2.6.24开始完全符合该标准。在linux系统上，它被记录在MAN7功能下。我目前正在开发的一个httpd守护进程中使用libcap api，以及epoll api，它也是linux特有的。是的，特别是因为最初的策略是启动所有X应用程序（从命令行）时传递几何体。