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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev