Open×××可以push到客户端的setenv

Open×××有了可以推送的setenv以及反向的push-peer-info之后，理论上可以实现任意信息的双向推送，这实在太方便了，然而方便是需要付出代价的，那就是容易混乱和出错以及带来安全性的缺失。这个世界上，有两个相互敌视力的群体一直存在着，一个是如何使得节点更加互通，另一个就是如何针对通信进行访问控制。换句话就是有人希望人人都能互通，有人却希望人与人之间的通信受到控制，这也是计算机网络的现状。正好Open×××作为一个虚拟的网络实现，它模拟了一台网络设备，该设备也同样要扮演上述的两类角色中的之一角。

Open×××之所以没有雷厉风行的实现push-peer-info正是纠结于上述两个共存的矛盾，你希望打开所有人家的门，但是却不想让任何人打开你家的门，对于Open×××，它同时扮演了两类角色，因为它既有客户端又有服务器。抛开客户端的push-peer-info不谈，因为这个在以前的文章中已经谈过了，下面说说服务器端可以push的setenv会有什么问题。用一句话说，那就是这样对于客户端而言是不安全的。

不安全的因素何在？我们知道Open×××内置了丰富的事件接口可以为外部程序联动，我们可以使用plugin或者script来做到这些。我们知道，在常见的操作系统中，每一个可以执行程序都用一些所谓的环境变量，这体现在main函数的第三个参数，如果熟悉exec系统调用也可以从其参数中看出这点，这些环境变量影响了程序的行为，如果这么说有点抽象，那么就具体说一个环境变量LD_PRELOAD，这是一个很危险的环境变量，它可以更改系统库函数的行为到你自定义的同名库函数，说白了就是提供了一个系统库函数重载的接口，因此该环境变量在灵活的背后也隐藏了很多危险。具体可以参见这篇博文：《

警惕UNIX下的LD_PRELOAD环境变量

》。如果Open×××服务器端push过来这么一个LD_PRELOAD环境变量，然后客户端执行了一个script或者在其plugin中exec了一个外部程序，那么客户端将面临被劫持的危险。

Open×××本来是一个让网络更安全的软件，它决不能做这种坏事，那么它是怎么解决的呢？Open×××为每一个option都绑定了一个permission用于区分这个option是自己配置的还是对端push过来的，对于某些具有潜在危险的option，比如setenv，将在apply对端push的option的时候，在permission中体现为deny，这样就不再接受这个option。然而同时又不能为了安全性而损失灵活性，因此Open×××提供了一个setenv-safe这个可以安全push到对端的option，它为什么安全呢？因为它在你push到对端的环境变量前面加了一个magic值，很简单，就是一个字符串“OPEN×××_”，即使你push了一个LD_PRELOAD，Open×××也会将其改为OPEN×××_LD_PRELOAD，而操作系统是不认识这个环境变量的，从而保证了安全。

有很多关于Open×××为何这么设计而不那么设计的争论，其实光看代码根本找不到答案，有时候一些蛛丝马迹还得从代码注释，Changelog或者其maillist中去寻找。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。