Writing an API-Test for localspl.dll

[Colin Finck]

Hi all,

In order to verify the exact behaviour of localspl.dll on Windows Server
2003, I'm trying to write an API-Test for it. This is no problem for
winspool.drv or even the Print Processor functions of localspl.dll, but
its Print Provider functions pose some serious problems:

* You get a table of function pointers by calling InitializePrintProvidor.

* Instead of just handing over the pointers, this function first calls
many undocumented ones from spoolss.dll, including CacheAddName,
CacheCreateAndAddNode, GetServerPolicy, SplInitializeWinSpoolDrv,
SplIsUpgrade.

* Out of these undocumented functions, GetServerPolicy is the most
problematic one, because it itself relies on a function pointer given by
spoolsv.exe to spoolss.dll in an initialization function. My API-Test is
not spoolsv.exe, so I don't initialize spoolss.dll the same way. Thus,
GetServerPolicy will fail and InitializePrintProvidor as well.

* For now, I worked around this problem by stubbing these functions in
my spoolss.dll. I.e., GetServerPolicy just returns TRUE there and I get
further.

* On top of this, InitializePrintProvidor also makes use of
RevertToPrinterSelf and ImpersonatePrinterClient. To let these functions
succeed, the current thread actually needs to impersonate a user. For
now, I worked around this problem by doing:

	OpenProcessToken(GetCurrentProcess(), TOKEN_DUPLICATE, &hToken);
	DuplicateToken(hToken, SecurityImpersonation, &hDup);
	ImpersonateLoggedOnUser(hDup);

before calling InitializePrintProvidor.

* Finally, this lets InitializePrintProvidor succeed and it gave me the
table of function pointers.
Unfortunately, even simple query functions like fpEnumPrinters do a
RevertToPrinterSelf and then expect to be in the SYSTEM context of
spoolsv.exe. When my API-Test was just run in a usual Administrator user
context under Windows Server 2003, fpEnumPrinters didn't succeed.
For now, I worked around this problem by running my test program as a
service in the SYSTEM context.


With all these problems presented, can you think of any way how I can
now write a reliable API-Test for localspl.dll that could be run
regularly under Windows Server 2003 and ReactOS?

One idea would be to load the system spoolss.dll and then rewire the
GetServerPolicy import to a function that just returns TRUE all the time.
Still then, I have the problem that my API-Test would need to be run in
the SYSTEM security context.

Creative ideas are welcome! :)


Cheers,

Colin

[Thomas Faber]

You can register your test as a service to be able to run it as SYSTEM. A bunch if
Wine's tests do this, e.g. advapi32:service and services:service.

To solve the other problem, one option might be to inject a thread into the spooler
process and run your test code there. Not sure if we already have code to do this anywhere
though.

On June 7, 2015 1:56:39 PM CEST, Colin Finck <colin(a)reactos.org> wrote:
>  Hi all,
>
> In order to verify the exact behaviour of localspl.dll on Windows
> Server
> 2003, I'm trying to write an API-Test for it. This is no problem for
> winspool.drv or even the Print Processor functions of localspl.dll, but
> its Print Provider functions pose some serious problems:
>
> * You get a table of function pointers by calling
> InitializePrintProvidor.
>
> * Instead of just handing over the pointers, this function first calls
> many undocumented ones from spoolss.dll, including CacheAddName,
> CacheCreateAndAddNode, GetServerPolicy, SplInitializeWinSpoolDrv,
> SplIsUpgrade.
>
> * Out of these undocumented functions, GetServerPolicy is the most
> problematic one, because it itself relies on a function pointer given
> by
> spoolsv.exe to spoolss.dll in an initialization function. My API-Test
> is
> not spoolsv.exe, so I don't initialize spoolss.dll the same way. Thus,
> GetServerPolicy will fail and InitializePrintProvidor as well.
>
> * For now, I worked around this problem by stubbing these functions in
> my spoolss.dll. I.e., GetServerPolicy just returns TRUE there and I get
> further.
>
> * On top of this, InitializePrintProvidor also makes use of
> RevertToPrinterSelf and ImpersonatePrinterClient. To let these
> functions
> succeed, the current thread actually needs to impersonate a user. For
> now, I worked around this problem by doing:
>
> 	OpenProcessToken(GetCurrentProcess(), TOKEN_DUPLICATE, &hToken);
> 	DuplicateToken(hToken, SecurityImpersonation, &hDup);
> 	ImpersonateLoggedOnUser(hDup);
>
> before calling InitializePrintProvidor.
>
> * Finally, this lets InitializePrintProvidor succeed and it gave me the
> table of function pointers.
> Unfortunately, even simple query functions like fpEnumPrinters do a
> RevertToPrinterSelf and then expect to be in the SYSTEM context of
> spoolsv.exe. When my API-Test was just run in a usual Administrator
> user
> context under Windows Server 2003, fpEnumPrinters didn't succeed.
> For now, I worked around this problem by running my test program as a
> service in the SYSTEM context.
>
>
> With all these problems presented, can you think of any way how I can
> now write a reliable API-Test for localspl.dll that could be run
> regularly under Windows Server 2003 and ReactOS?
>
> One idea would be to load the system spoolss.dll and then rewire the
> GetServerPolicy import to a function that just returns TRUE all the
> time.
> Still then, I have the problem that my API-Test would need to be run in
> the SYSTEM security context.
>
> Creative ideas are welcome! :)
>
>
> Cheers,
>
> Colin
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.