编写安全的SQL Server扩大存储历程[MSSQL防范]

 sql server 的扩大存储历程,其实就是一个普通的 Windows DLL,只不过按照某种法则实现了某些函数罢了.
　　近日在写一个扩大存储历程时,发现再写这类动态库时,还是有一些需求分外注意的地方.之所以会分外注意,是因为DLL运行于SQL Server的地址空间,而SQL Server毕竟是怎么举行线程调度的,却不是我们能理解的,即便理解也无法掌握.
　　我们写动态库普通是自己用,即便给别人用,也很少像SQL Server这样,一个动态库很有大概加载多次,并且都是加载到一个进程的地址空间中.我们知道,当一个动态库加载到进程的地址空间时,DLL全部全局与部分变量初始化且仅初始化一次,今后再次调用 LoadLibrary函数时,仅仅增添其引用计数罢了,那么很明显,假定有一全局 int ,初始化为0,调用一个函数另其自加,此时其值为1,然后再调用LoadLibray,并操纵返回的句柄调用输出函数输出该值,固然调用者认为自己加载后当即输出,然后该值确切1而不是0.windows是进程独立的,而在线程方面,假定不注意,上面的情形极大概会程序员带来麻烦.
　　介绍一下我的扩大存储历程,该动态库导出了三个函数: Init,work,Final,Init读文件,存储信息于内存,work简单的只是向该内存检索信息,Final回收内存.如上所说,假定不考虑同一进程空间多次加载问题,两次调用Init将造成无谓的浪费,因为我第一次已经读进了内存,如果通过堆分配内存,还会造成内存泄露.
　　我利用的引用计数办理的该问题,代码很短,直接贴上来:
#include "stdafx.h"
#include <string>
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);
}
　　
我想固然看上去不是很高超,但是问题应当是办理了的.
　　
还有一点阐明,为什么不利用Tls,诚恳说,我考虑过利用的,因为其实代码是有一点问题的,假定一个用户调用xp_part_init,然后另一个用户也调用xp_part_init,注意我们的存储历程但是服务器端的,然后第一个用户调用xp_part_finalize,那么会怎样,他仍旧可以正常利用xp_part_process,这倒无所谓,但是第一个用户调用两次xp_part_finalize,就可以够影响第二个用户了,他的xp_part_process将返回错误.
　　
利用Tls 仿佛可以办理这问题,比方再增添一个tls_index变量,调用 TlsSetValue保存用户私人数据,TlsGetValue检索私人数据,当xp_part_init时,假定该私人数据为0,履行正常的初始化历程,（即上面的xp_part_init）履行成功后存储私人数据为1,假定是1,直接返回,xp_part_finalize时,假定私人数据为1,则履行正常的xp_part_finalize,然后设私人数据为0,假定是0,直接返回.
　　
仿佛设法还是不错的,这样断绝了多个用户,安全性仿佛提高了不少,但是事实是不可行的.因为Tls保存的并非私人数据,而是线程本地变量,我们不能保证一个用户的多次操作都是用同一个线程履行的,这个由SQL Server自己掌握,事实上我在查询解析器里多次履行的后果显示,SQL Server内部仿佛利用了一个线程池.既然如此,那这种设法也只能作罢.