编写安全的SQL Server扩大存储进程-交流共享-唐山网站建设

编写安全的SQL Server扩大存储进程

核心提示：SQL Server 的扩大存储进程，实在就是1个普通的 Windows DLL,只不过依照某种规则实现了某些函数而已...

SQL Server 的扩大存储进程，实在就是1个普通的 Windows DLL,只不过依照某种规则实现了某些函数而已。

近日在写1个扩大存储进程时，发现再写这类动态库时，还是有1些需要特别留意的地方。之所以会特别留意，是由于DLL运行于SQL Server的地址空间，而SQL Server究竟是怎样进行线程调度的，却不是我们能了解的，即使了解也没法控制。

我们写动态库1般是自己用，即使给他人用，也很少像SQL Server这样，1个动态库很有可能加载屡次，并且都是加载到1个进程的地址空间中。我们知道，当1个动态库加载到进程的地址空间时，DLL所有全局与局部变量初始化且仅初始化1次，以后再次调用 LoadLibrary函数时，仅仅增加其援用计数而已，那末很明显，假设有1全局 int ,初始化为0，调用1个函数另其自加，此时其值为1,然后再调用LoadLibray,并利用返回的句柄调用输出函数输出该值，固然调用者觉得自己加载后立即输出，然后该值确切1而不是0。windows是进程独立的，而在线程方面，假设不留意，上面的情况很可能会程序员带来麻烦。

先容1下我的扩大存储进程，该动态库导出了3个函数: Init,work,Final,Init读文件，存储信息于内存，work简单的只是向该内存检索信息,Final回收内存。如上所说，假设不考虑同1进程空间屡次加载题目，两次调用Init将造成无谓的浪费，由于我第1次已读进了内存，要是通过堆分配内存，还会造成内存泄漏。

我使用的援用计数解决的该题目，代码很短，直接贴上来：

以下为援用的内容：
#include "stdafx.h"
#include
using namespace std;
extern "C" {
RETCODE __declspec(dllexport) xp_part_init(SRV_PROC *srvproc);
RETCODE __declspec(dllexport) xp_part_process(SRV_PROC *srvproc);
RETCODE __declspec(dllexport) xp_part_finalize(SRV_PROC *srvproc);
}
#define XP_NOERROR 0
#define XP_ERROR 1
HINSTANCE hInst = NULL;
int nRef = 0;
void printError (SRV_PROC *pSrvProc, CHAR* szErrorMsg);
ULONG __GetXpVersion(){ return ODS_VERSION;}
SRVRETCODE xp_part_init(SRV_PROC* pSrvProc){
typedef bool (*Func)();
if(nRef == 0){
hInst = ::LoadLibrary("part.dll");
if(hInst == NULL){
printError(pSrvProc,"不能加载part.dll");
return XP_ERROR;
}
Func theFunc = (Func)::GetProcAddress(hInst,"Init");
if(!theFunc()){
::FreeLibrary(hInst);
printError(pSrvProc,"不能取得分类号与专辑的对应表");
return XP_ERROR;
}
}
++ nRef;
return (XP_NOERROR);
}
SRVRETCODE xp_part_process(SRV_PROC* pSrvProc){
typedef bool (*Func)(char*);
if(nRef == 0){
printError(pSrvProc,"函数还没有初始化,请首先调用xp_part_init");
return XP_ERROR;
}
Func theFunc = (Func)::GetProcAddress(hInst,"Get");
BYTE bType;
ULONG cbMaxLen,cbActualLen;
BOOL fNull;
char szInput[256] = {0};
if (srv_paraminfo(pSrvProc, 1, &bType, (ULONG*)&cbMaxLen, (ULONG*)&cbActualLen, (BYTE*)szInput, &fNull) == FAIL){
printError(pSrvProc,"srv_paraminfo 返回 FAIL");
return XP_ERROR;
}
szInput[cbActualLen] = 0;
string strInput = szInput;
string strOutput = ";";
int cur,old = 0;
while(string::npos != (cur = strInput.find(’;’,old)) ){
strncpy(szInput,strInput.c_str() + old,cur - old);
szInput[cur - old] = 0;
old = cur + 1;
theFunc(szInput);
if(string::npos ==strOutput.find((string)";" + szInput))
strOutput += szInput;
}
strcpy(szInput,strOutput.c_str());
if (FAIL == srv_paramsetoutput(pSrvProc, 1, (BYTE*)(szInput + 1), strlen(szInput) - 1,FALSE)){
printError (pSrvProc, "srv_paramsetoutput 调用失败");
return XP_ERROR;
}
srv_senddone(pSrvProc, (SRV_DONE_COUNT | SRV_DONE_MORE), 0, 0);
return XP_NOERROR;
}
SRVRETCODE xp_part_finalize(SRV_PROC* pSrvProc){
typedef void (*Func)();
if(nRef == 0)
return XP_NOERROR;
Func theFunc = (Func)::GetProcAddress(hInst,"Fin");
if((--nRef) == 0){
theFunc();
::FreeLibrary(hInst);
hInst = NULL;
}
return (XP_NOERROR);
}

　　
我想固然看上往不是很高明，但是题目应当是解决了的。
　　
还有1点说明，为甚么不使用Tls，老实说，我考虑过使用的，由于实在代码是有1点题目的，假设1个用户调用xp_part_init,然后另1个用户也调用xp_part_init，留意我们的存储进程可是服务器真个，然后第1个用户调用xp_part_finalize，那末会怎样，他依然可以正常使用xp_part_process，这倒无所谓，但是第1个用户调用两次xp_part_finalize，便可以够影响第2个用户了，他的xp_part_process将返回毛病。
　　
使用Tls 仿佛可以解决这题目，例如再添加1个tls_index变量，调用 TlsSetValue保存用户私人数据，TlsGetValue检索私人数据，当xp_part_init时，假设该私人数据为0，履行正常的初始化进程，（即上面的xp_part_init）履行成功后存储私人数据为1，假设是1，直接返回，xp_part_finalize时，假设私人数据为1，则履行正常的xp_part_finalize，然后设私人数据为0，假设是0，直接返回。
　　
仿佛想法还是不错的，这样隔离了多个用户，安全性仿佛进步了很多，但是事实是不可行的。由于Tls保存的其实不是私人数据，而是线程本地变量，我们不能保证1个用户的屡次操纵都是用同1个线程履行的，这个由SQL Server自己控制，事实上我在查询分析器里屡次履行的结果显示，SQL Server内部仿佛使用了1个线程池。既然如此，那这类想法也只能作罢。

唐山网站建设www.fw8.net

TAG:用户,进程,函数,私人,线程

评论加载中...