在linux下,是不是可以被主程序调用的程序都能算作插件,如.so共享库,独立的二进制可执行文件,其他形式不太清楚了,
采用.so共享库有个问题,就是不同平台编译的库存在兼容性问题,在一个平台上编译的库不一定能在另一台机子上正常调用(如gcc版本不一样),不知道有什么解决办法,
二进制形式的,好像直接可以exec调用了,不存在兼容性问题,但总感觉怪怪的,
有个安全性问题,就是如何验证主程序与插件之间调用的合法性,就是保证主程序调用的插件一定没有被替代或篡改过,还有插件一定是被合法的主程序调用,不知道怎么解决
小弟刚接触linux开发,大家帮着讨论一下这些问题,可以畅所欲言
8 个解决方案
#1
正因为如此,所以so后面都跟版本号,比如some.so.0.0.1
插件其实就是DLL。
Linux下的DLL和Windows下略有不同。
要验证合法性,一般是通过调用函数后看返回值。
插件其实就是DLL。
Linux下的DLL和Windows下略有不同。
要验证合法性,一般是通过调用函数后看返回值。
#2
顶
#3
多谢Loader的回复,
我现在是想程序采用的插件的架构,比较方便,灵活,但采用.so库,运行环境太多,不可能每个环境都编一个版本,
所以考虑直接搞成二进制文件形式,直接调用,
------------------------------------
要验证合法性,一般是通过调用函数后看返回值。
--------------------------------------
看返回值?都执行过了,那怎么叫验证,要在插件执行前保证双方的合法性,万一插件是病毒,木马呢,
我现在是想程序采用的插件的架构,比较方便,灵活,但采用.so库,运行环境太多,不可能每个环境都编一个版本,
所以考虑直接搞成二进制文件形式,直接调用,
------------------------------------
要验证合法性,一般是通过调用函数后看返回值。
--------------------------------------
看返回值?都执行过了,那怎么叫验证,要在插件执行前保证双方的合法性,万一插件是病毒,木马呢,
#4
linux下的软件以源代码形式的发布居多,有源代码了都是在其它系统上编译。
绝大部分要求的是linux的内核版本,还有其它开源项目的依赖性。
绝大部分要求的是linux的内核版本,还有其它开源项目的依赖性。
#5
恩,就是内核版本不一样,gcc的版本也不一样,这些安装插件的机器都是远程维护的,大部分没法直接操作,没办法去在每台上都编译一个版本,另外可能以后还要扩展其他插件,所以。。。
#6
学习。
#7
唉,还是沉了,等待高手来。。。。。
#8
http://www.bjwtnd.cn/zgc
#1
正因为如此,所以so后面都跟版本号,比如some.so.0.0.1
插件其实就是DLL。
Linux下的DLL和Windows下略有不同。
要验证合法性,一般是通过调用函数后看返回值。
插件其实就是DLL。
Linux下的DLL和Windows下略有不同。
要验证合法性,一般是通过调用函数后看返回值。
#2
顶
#3
多谢Loader的回复,
我现在是想程序采用的插件的架构,比较方便,灵活,但采用.so库,运行环境太多,不可能每个环境都编一个版本,
所以考虑直接搞成二进制文件形式,直接调用,
------------------------------------
要验证合法性,一般是通过调用函数后看返回值。
--------------------------------------
看返回值?都执行过了,那怎么叫验证,要在插件执行前保证双方的合法性,万一插件是病毒,木马呢,
我现在是想程序采用的插件的架构,比较方便,灵活,但采用.so库,运行环境太多,不可能每个环境都编一个版本,
所以考虑直接搞成二进制文件形式,直接调用,
------------------------------------
要验证合法性,一般是通过调用函数后看返回值。
--------------------------------------
看返回值?都执行过了,那怎么叫验证,要在插件执行前保证双方的合法性,万一插件是病毒,木马呢,
#4
linux下的软件以源代码形式的发布居多,有源代码了都是在其它系统上编译。
绝大部分要求的是linux的内核版本,还有其它开源项目的依赖性。
绝大部分要求的是linux的内核版本,还有其它开源项目的依赖性。
#5
恩,就是内核版本不一样,gcc的版本也不一样,这些安装插件的机器都是远程维护的,大部分没法直接操作,没办法去在每台上都编译一个版本,另外可能以后还要扩展其他插件,所以。。。
#6
学习。
#7
唉,还是沉了,等待高手来。。。。。
#8
http://www.bjwtnd.cn/zgc